[PATCH V3 1/3] libxl: virtio: Remove unused frontend nodes

Only the VirtIO backend will watch xenstore to find out when a new instance needs to be created for a guest, and read the parameters from there. VirtIO frontend are only virtio, so they will not do anything with the xenstore nodes. They can be removed. While at it, also add a comment to the

[PATCH V3 3/3] 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 V3 0/3] libxl: Make grants configurable for virtio devices

Hi, This patchset intends to make grant mapping usage configurable for virtio devices. Currently they are forced enabled for backends running on non-Dom0 domains. This patchset adds a new `grant_usage` parameter for the virtio devices, which can be used to enable or disable grant mappings

[PATCH V3 2/3] libxl: Call libxl__virtio_devtype.set_default() early enough

The _setdefault() function for virtio devices is getting called after libxl__prepare_dtb(), which is late as libxl__prepare_dtb() expects the defaults to be already set by this time. Call libxl__virtio_devtype.set_default() from libxl__domain_config_setdefault(), in a similar way as other devices

[qemu-mainline test] 181089: regressions - FAIL

flight 181089 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/181089/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 30 leak-check/check/src_host fail REGR. vs. 180691

[linux-linus test] 181082: regressions - FAIL

flight 181082 linux-linus real [real] flight 181098 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181082/ http://logs.test-lab.xenproject.org/osstest/logs/181098/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

RE: [XEN][PATCH v7 14/19] common/device_tree: Add rwlock for dt_host

Hi Vikram, > -Original Message- > Subject: [XEN][PATCH v7 14/19] common/device_tree: Add rwlock for dt_host > > Dynamic programming ops will modify the dt_host and there might be other > function which are browsing the dt_host at the same time. To avoid the race > conditions, adding

RE: [XEN][PATCH v7 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree

Hi Vikram, > -Original Message- > Subject: [XEN][PATCH v7 08/19] xen/device-tree: Add > device_tree_find_node_by_path() to find nodes in device tree > > Add device_tree_find_node_by_path() to find a matching node with path for > a > dt_device_node. > > Reason behind this function: >

RE: [XEN][PATCH v7 05/19] xen/arm: Add CONFIG_OVERLAY_DTB

Hi Vikram, > -Original Message- > Subject: [XEN][PATCH v7 05/19] xen/arm: Add CONFIG_OVERLAY_DTB > > Introduce a config option where the user can enable support for > adding/removing > device tree nodes using a device tree binary overlay. > > Update SUPPORT.md and CHANGELOG.md to state

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

flight 181093 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/181093/ 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

[XEN][PATCH v7 17/19] tools/libs/ctrl: Implement new xc interfaces for dt overlay

xc_dt_overlay() sends the device tree binary overlay, size of .dtbo and overlay operation type i.e. add or remove to xen. Signed-off-by: Vikram Garhwal --- tools/include/xenctrl.h | 5 tools/libs/ctrl/Makefile.common | 1 + tools/libs/ctrl/xc_dt_overlay.c | 51

Re: [XEN][PATCH v6 16/19] xen/arm: Implement device tree node addition functionalities

Hi Michal, On 5/10/23 3:18 AM, Michal Orzel wrote: On 03/05/2023 01:36, Vikram Garhwal wrote: Update sysctl XEN_SYSCTL_dt_overlay to enable support for dtbo nodes addition using device tree overlay. xl dt-overlay add file.dtbo: Each time overlay nodes are added using .dtbo, a new

Re: [XEN][PATCH v6 17/19] tools/libs/ctrl: Implement new xc interfaces for dt overlay

Hi Anthony, On 5/18/23 9:01 AM, Anthony PERARD wrote: On Tue, May 02, 2023 at 04:36:48PM -0700, Vikram Garhwal wrote: xc_dt_overlay() sends the device tree binary overlay, size of .dtbo and overlay operation type i.e. add or remove to xen. Signed-off-by: Vikram Garhwal Reviewed-by: Anthony

[XEN][PATCH v7 19/19] tools/xl: Add new xl command overlay for device tree overlay support

Signed-off-by: Vikram Garhwal Reviewed-by: Anthony PERARD --- tools/xl/xl.h | 1 + tools/xl/xl_cmdtable.c | 6 + tools/xl/xl_vmcontrol.c | 52 + 3 files changed, 59 insertions(+) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index

[XEN][PATCH v7 13/19] asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h

Dynamic programming ops will modify the dt_host and there might be other function which are browsing the dt_host at the same time. To avoid the race conditions, adding rwlock for browsing the dt_host. But adding rwlock in device_tree.h causes following circular dependency:

[XEN][PATCH v7 18/19] tools/libs/light: Implement new libxl functions for device tree overlay ops

Signed-off-by: Vikram Garhwal Reviewed-by: Anthony PERARD --- tools/include/libxl.h | 11 + tools/libs/light/Makefile | 3 ++ tools/libs/light/libxl_dt_overlay.c | 71 + 3 files changed, 85 insertions(+) create mode 100644

[XEN][PATCH v7 12/19] xen/smmu: Add remove_device callback for smmu_iommu ops

Add remove_device callback for removing the device entry from smmu-master using following steps: 1. Find if SMMU master exists for the device node. 2. Check if device is currently in use. 3. Remove the SMMU master. Signed-off-by: Vikram Garhwal Reviewed-by: Luca Fancellu Reviewed-by: Michal

[XEN][PATCH v7 14/19] common/device_tree: Add rwlock for dt_host

Dynamic programming ops will modify the dt_host and there might be other function which are browsing the dt_host at the same time. To avoid the race conditions, adding rwlock for browsing the dt_host during runtime. Reason behind adding rwlock instead of spinlock: For now, dynamic

[XEN][PATCH v7 16/19] xen/arm: Implement device tree node addition functionalities

Update sysctl XEN_SYSCTL_dt_overlay to enable support for dtbo nodes addition using device tree overlay. xl dt-overlay add file.dtbo: Each time overlay nodes are added using .dtbo, a new fdt(memcpy of device_tree_flattened) is created and updated with overlay nodes. This updated fdt

[XEN][PATCH v7 15/19] xen/arm: Implement device tree node removal functionalities

Introduce sysctl XEN_SYSCTL_dt_overlay to remove device-tree nodes added using device tree overlay. xl dt-overlay remove file.dtbo: Removes all the nodes in a given dtbo. First, removes IRQ permissions and MMIO accesses. Next, it finds the nodes in dt_host and delete the device node

[XEN][PATCH v7 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller

Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_locked(). Remove static type so this can also be used by SMMU drivers to check if the device is being used before removing. Moving spin_lock to caller was done to prevent the concurrent access to iommu_dt_device_is_assigned while

[XEN][PATCH v7 01/19] common/device_tree: handle memory allocation failure in __unflatten_device_tree()

Change __unflatten_device_tree() return type to integer so it can propagate memory allocation failure. Add panic() in dt_unflatten_host_device_tree() for memory allocation failure during boot. Fixes: fb97eb614acf ("xen/arm: Create a hierarchical device tree") Signed-off-by: Vikram Garhwal

[XEN][PATCH v7 07/19] libfdt: overlay: change overlay_get_target()

Rename overlay_get_target() to fdt_overlay_target_offset() and remove static function type. This is done to get the target path for the overlay nodes which is very useful in many cases. For example, Xen hypervisor needs it when applying overlays because Xen needs to do further processing of the

[XEN][PATCH v7 11/19] xen/iommu: Introduce iommu_remove_dt_device()

Remove master device from the IOMMU. This will be helpful when removing the overlay nodes using dynamic programming during run time. Signed-off-by: Vikram Garhwal Reviewed-by: Michal Orzel Acked-by: Jan Beulich --- xen/drivers/passthrough/device_tree.c | 41 +++

[XEN][PATCH v7 03/19] xen/arm/device: Remove __init from function type

Remove __init from following function to access during runtime: 1. map_irq_to_domain() 2. handle_device_interrupts() 3. map_range_to_domain() 4. unflatten_dt_node() Move map_irq_to_domain() prototype from domain_build.h to setup.h. To avoid breaking the build, following changes

[XEN][PATCH v7 10/19] xen/iommu: protect iommu_add_dt_device() with dtdevs_lock

Protect iommu_add_dt_device() with dtdevs_lock to prevent concurrent access add. Signed-off-by: Vikram Garhwal Reviewed-by: Luca Fancellu Reviewed-by: Michal Orzel --- xen/drivers/passthrough/device_tree.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[XEN][PATCH v7 05/19] xen/arm: Add CONFIG_OVERLAY_DTB

Introduce a config option where the user can enable support for adding/removing device tree nodes using a device tree binary overlay. Update SUPPORT.md and CHANGELOG.md to state the Device Tree Overlays support for Arm. Signed-off-by: Vikram Garhwal --- Changes from v6: Add CHANGELOG and

[XEN][PATCH v7 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree

Add device_tree_find_node_by_path() to find a matching node with path for a dt_device_node. Reason behind this function: Each time overlay nodes are added using .dtbo, a new fdt(memcpy of device_tree_flattened) is created and updated with overlay nodes. This updated fdt is further

[XEN][PATCH v7 06/19] libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB.

This is done to access fdt library function which are required for adding device tree overlay nodes for dynamic programming of nodes. Signed-off-by: Vikram Garhwal Acked-by: Julien Grall --- xen/common/libfdt/Makefile | 4 1 file changed, 4 insertions(+) diff --git

[XEN][PATCH v7 02/19] common/device_tree.c: unflatten_device_tree() propagate errors

This will be useful in dynamic node programming when new dt nodes are unflattend during runtime. Invalid device tree node related errors should be propagated back to the caller. Signed-off-by: Vikram Garhwal Reviewed-by: Henry Wang --- xen/common/device_tree.c | 15 +-- 1 file

[XEN][PATCH v7 04/19] common/device_tree: change __unflatten_device_tree() type

Following changes are done to __unflatten_device_tree(): 1. __unflatten_device_tree() is renamed to unflatten_device_tree(). 2. Remove __init and static function type. Signed-off-by: Vikram Garhwal Reviewed-by: Henry Wang --- xen/common/device_tree.c | 9 -

[XEN][PATCH v7 00/19] dynamic node programming using overlay dtbo

Hi, This patch series is for introducing dynamic programming i.e. add/remove the devices during run time. Using "xl dt_overlay" a device can be added/removed with dtbo. For adding a node using dynamic programming: 1. flatten device tree overlay node will be added to a fdt 2. Updated fdt

Re: [ANNOUNCE] KVM Microconference at LPC 2023

On Thu, Jun 01, 2023, Micka�l Sala�n wrote: > Hi, > > What is the status of this microconference proposal? We'd be happy to talk > about Heki [1] and potentially other hypervisor supports. Proposal submitted (deadline is/was today), now we wait :-) IIUC, we should find out rather quickly

[ovmf test] 181091: all pass - PUSHED

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

Re: [ANNOUNCE] KVM Microconference at LPC 2023

Hi, What is the status of this microconference proposal? We'd be happy to talk about Heki [1] and potentially other hypervisor supports. Regards, Mickaël [1] https://lore.kernel.org/all/20230505152046.6575-1-...@digikod.net/ On 26/05/2023 18:09, Mickaël Salaün wrote: See James Morris's

[PATCH 1/2] xen-blkback: Implement diskseq checks

This allows specifying a disk sequence number in XenStore. If it does not match the disk sequence number of the underlying device, the device will not be exported and a warning will be logged. Userspace can use this to eliminate race conditions due to major/minor number reuse. Old kernels do not

[PATCH 2/2] xen-blkback: Inform userspace that device has been opened

Set "opened" to "0" before the hotplug script is called. Once the device node has been opened, set "opened" to "1". "opened" is used exclusively by userspace. It serves two purposes: 1. It tells userspace that the diskseq Xenstore entry is supported. 2. It tells userspace that it can wait for

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

flight 181079 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/181079/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail in 181061 pass in 181079 test-amd64-amd64-pair

[PATCH 0/2] xen/blkback: support delete-on-close block devices

These two patches allow userspace to provide an expected diskseq of a block device and discover when blkback has opened the device. Together, these features allow using blkback with delete-on-close block devices, such as loop devices with autoclear set. Demi Marie Obenour (2): xen-blkback:

Re: [PATCH v3 03/34] s390: Use pt_frag_refcount for pagetables

On Thu, Jun 1, 2023 at 6:19 AM Gerald Schaefer wrote: > > On Wed, 31 May 2023 14:30:01 -0700 > "Vishal Moola (Oracle)" wrote: > > > s390 currently uses _refcount to identify fragmented page tables. > > The page table struct already has a member pt_frag_refcount used by > > powerpc, so have s390

Re: [PATCH v6 5/6] xen/riscv: introduce an implementation of macros from

On Thu, 2023-06-01 at 09:59 +0200, Jan Beulich wrote: > On 31.05.2023 22:06, Oleksii wrote: > > On Tue, 2023-05-30 at 18:00 +0200, Jan Beulich wrote: > > > > +static uint32_t read_instr(unsigned long pc) > > > > +{ > > > > +    uint16_t instr16 = *(uint16_t *)pc; > > > > + > > > > +    if (

[ovmf test] 181087: all pass - PUSHED

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

[qemu-mainline test] 181068: regressions - FAIL

flight 181068 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/181068/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 180691

Re: [PATCH v2] iscsi_ibft: Fix finding the iBFT under Xen Dom 0

On 01/06/2023 6:08 pm, Dave Hansen wrote: > On 6/1/23 09:57, Dave Hansen wrote: >> On 5/30/23 08:01, Ross Lagerwall wrote: >>> Since firmware doesn't indicate the iBFT in the E820, add a reserved >>> region so that it gets identity mapped when running as Dom 0 so that it >>> is possible to search

[PATCH] x86: Add Kconfig option to require NX bit support

This allows replacing many instances of runtime checks with folded constants. The patch asserts support for the NX bit in PTEs at boot time and if so short-circuits cpu_has_nx to 1. This has several knock-on effects that improve codegen: * _PAGE_NX matches _PAGE_NX_BIT, optimising the macro to a

Re: [PATCH v2] iscsi_ibft: Fix finding the iBFT under Xen Dom 0

On 6/1/23 09:57, Dave Hansen wrote: > On 5/30/23 08:01, Ross Lagerwall wrote: >> Since firmware doesn't indicate the iBFT in the E820, add a reserved >> region so that it gets identity mapped when running as Dom 0 so that it >> is possible to search for it. Move the call to reserve_ibft_region()

Re: [PATCH v2] iscsi_ibft: Fix finding the iBFT under Xen Dom 0

On 5/30/23 08:01, Ross Lagerwall wrote: > Since firmware doesn't indicate the iBFT in the E820, add a reserved > region so that it gets identity mapped when running as Dom 0 so that it > is possible to search for it. Move the call to reserve_ibft_region() > later so that it is called after the Xen

[ovmf test] 181081: all pass - PUSHED

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

Re: [PATCH] x86/ucode: Exit early from early_update_cache() if loading not available

On Thu, Jun 01, 2023 at 03:38:13PM +0100, Andrew Cooper wrote: > If for any reason early_microcode_init() concludes that no microcode loading > is available, early_update_cache() will fall over a NULL function pointer: > > (XEN) Xen call trace: > (XEN)[] R show_code+0x91/0x18f > (XEN)

Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users

On Thu, Jun 01, 2023 at 07:25:46PM +0300, Andy Shevchenko wrote: > On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote: > > On Tue, 30 May 2023 at 23:34, Bjorn Helgaas wrote: > > > On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote: ... > > > Where are we at? Are we going

Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users

On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote: > On Tue, 30 May 2023 at 23:34, Bjorn Helgaas wrote: > > On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote: > > > On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote: > > > > On Tue, May 09, 2023 at 01:21:22PM

Re: [linux-linus test] 181063: regressions - FAIL

On Thu, Jun 01, 2023 at 01:20:26PM +, osstest service owner wrote: > flight 181063 linux-linus real [real] > flight 181077 linux-linus real-retest [real] > http://logs.test-lab.xenproject.org/osstest/logs/181063/ > http://logs.test-lab.xenproject.org/osstest/logs/181077/ > > Regressions :-( >

[PULL 1/8] block: add blk_io_plug_call() API

Introduce a new API for thread-local blk_io_plug() that does not traverse the block graph. The goal is to make blk_io_plug() multi-queue friendly. Instead of having block drivers track whether or not we're in a plugged section, provide an API that allows them to defer a function call until we're

[PULL 8/8] qapi: add '@fdset' feature for BlockdevOptionsVirtioBlkVhostVdpa

From: Stefano Garzarella The virtio-blk-vhost-vdpa driver in libblkio 1.3.0 supports the fd passing through the new 'fd' property. Since now we are using qemu_open() on '@path' if the virtio-blk driver supports the fd passing, let's announce it. In this way, the management layer can pass the

[PULL 6/8] block: remove bdrv_co_io_plug() API

No block driver implements .bdrv_co_io_plug() anymore. Get rid of the function pointers. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Stefano Garzarella Acked-by: Kevin Wolf Message-id: 20230530180959.1108766-7-stefa...@redhat.com Signed-off-by: Stefan Hajnoczi ---

[PULL 5/8] block/linux-aio: convert to blk_io_plug_call() API

Stop using the .bdrv_co_io_plug() API because it is not multi-queue block layer friendly. Use the new blk_io_plug_call() API to batch I/O submission instead. Note that a dev_max_batch check is dropped in laio_io_unplug() because the semantics of unplug_fn() are different from .bdrv_co_unplug():

[PULL 2/8] block/nvme: convert to blk_io_plug_call() API

Stop using the .bdrv_co_io_plug() API because it is not multi-queue block layer friendly. Use the new blk_io_plug_call() API to batch I/O submission instead. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Stefano Garzarella Acked-by: Kevin Wolf Message-id:

[PULL 7/8] block/blkio: use qemu_open() to support fd passing for virtio-blk

From: Stefano Garzarella Some virtio-blk drivers (e.g. virtio-blk-vhost-vdpa) supports the fd passing. Let's expose this to the user, so the management layer can pass the file descriptor of an already opened path. If the libblkio virtio-blk driver supports fd passing, let's always use

[PULL 4/8] block/io_uring: convert to blk_io_plug_call() API

Stop using the .bdrv_co_io_plug() API because it is not multi-queue block layer friendly. Use the new blk_io_plug_call() API to batch I/O submission instead. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Stefano Garzarella Acked-by: Kevin Wolf Message-id:

[PULL 3/8] block/blkio: convert to blk_io_plug_call() API

Stop using the .bdrv_co_io_plug() API because it is not multi-queue block layer friendly. Use the new blk_io_plug_call() API to batch I/O submission instead. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Stefano Garzarella Acked-by: Kevin Wolf Message-id:

[PULL 0/8] Block patches

The following changes since commit c6a5fc2ac76c5ab709896ee1b0edd33685a67ed1: decodetree: Add --output-null for meson testing (2023-05-31 19:56:42 -0700) are available in the Git repository at: https://gitlab.com/stefanha/qemu.git tags/block-pull-request for you to fetch changes up to

Re: [PATCH] x86/ucode: Exit early from early_update_cache() if loading not available

On 01.06.2023 16:38, Andrew Cooper wrote: > If for any reason early_microcode_init() concludes that no microcode loading > is available, early_update_cache() will fall over a NULL function pointer: > > (XEN) Xen call trace: > (XEN)[] R show_code+0x91/0x18f > (XEN)[] F

[PATCH v2 3/3] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

The RSBA bit, "RSB Alternative", means that the RSB may use alternative predictors when empty. From a practical point of view, this mean "Retpoline not safe". Enhanced IBRS (officially IBRS_ALL in Intel's docs, previously IBRS_ATT) is a statement that IBRS is implemented in hardware (as opposed

[PATCH v2 2/3] x86/spec-ctrl: Fix up the RSBA/RRSBA bits as appropriate

In order to level a VM safely for migration, the toolstack needs to know the RSBA/RRSBA properties of the CPU, whether or not they happen to be enumerated. See the code comment for details. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu v2: * Rewrite

[PATCH v2 0/3] x86: RSBA and RRSBA handling

This series deals with the hanlding of the RSBA and RRSBA bits across all parts and all mistakes encountered in various microcode versions. There are substantial changes from v1, following a clarification from Intel. Importantly, CPUs are not expected to enumerate both RSBA and RRSBA, therefore

[PATCH v2 1/3] x86/spec-ctrl: Rename retpoline_safe() to retpoline_calculations()

This is prep work, split out to simply the diff on the following change. * Rename to retpoline_calculations(), and call unconditionally. It is shortly going to synthesise missing enumerations required for guest safety. * For the model check switch statement, store the result in a variable

[PATCH] x86/ucode: Exit early from early_update_cache() if loading not available

If for any reason early_microcode_init() concludes that no microcode loading is available, early_update_cache() will fall over a NULL function pointer: (XEN) Xen call trace: (XEN)[] R show_code+0x91/0x18f (XEN)[] F show_execution_state+0x2d/0x1fc (XEN)[] F

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

On 01.06.23 16:33, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 03:22:33PM +0200, Borislav Petkov wrote: Now lemme restart testing. This is from another box, with the latest changes incorporated: https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=rc1-mtrr ---

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

On Thu, Jun 01, 2023 at 03:22:33PM +0200, Borislav Petkov wrote: > Now lemme restart testing. This is from another box, with the latest changes incorporated: https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=rc1-mtrr --- proc-mtrr.before2011-03-04 01:03:35.243994733 +0100 +++

[PATCH v1 5/7] xenalyze: sync with vmx.h, use EXIT_REASON_VMXON

Signed-off-by: Olaf Hering --- tools/xentrace/xenalyze.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index d2e6c77590..88c3d5f873 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -467,7

[PATCH v1 7/7] xenalyze: handle more potential exit reason values from vmx.h

Copy and use more constants from vmx.h, to turn numbers into strings. Adjust the REASON_MAX value accordingly. Remove the size constraint from string array, the compiler will grow it as needed. Signed-off-by: Olaf Hering --- tools/xentrace/xenalyze.c | 28 1 file

[PATCH v1 6/7] xenalyze: sync with vmx.h, use EXIT_REASON_MCE_DURING_VMENTRY

Signed-off-by: Olaf Hering --- tools/xentrace/xenalyze.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index 88c3d5f873..9635ff453a 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -479,7

[PATCH v1 1/7] xentrace: remove unimplemented option from man page

The documented option --usage worked because every unknown option showed the help. Signed-off-by: Olaf Hering --- docs/man/xentrace.8.pod | 4 1 file changed, 4 deletions(-) diff --git a/docs/man/xentrace.8.pod b/docs/man/xentrace.8.pod index 69aef05f65..4c174a84c0 100644 ---

[PATCH v1 4/7] xenalyze: sync with vmx.h, use EXIT_REASON_VMXOFF

Signed-off-by: Olaf Hering --- tools/xentrace/xenalyze.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index 1cae055ef4..d2e6c77590 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -466,7

[PATCH v1 3/7] xenalyze: sync with vmx.h, use EXIT_REASON_PENDING_VIRT_INTR

Signed-off-by: Olaf Hering --- tools/xentrace/xenalyze.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index a50538e9a8..1cae055ef4 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -447,7

[PATCH v1 2/7] xentrace: use correct output format for pit and rtc

The input values were always 32bit. Fixes 55ee5dea32 ("xentrace: add TRC_HVM_EMUL") Signed-off-by: Olaf Hering --- tools/xentrace/formats | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 0fcc327a40..afb5ee0112 100644

[PATCH v1 0/7] xentrace changes

Olaf Hering (7): xentrace: remove unimplemented option from man page xentrace: use correct output format for pit and rtc xenalyze: sync with vmx.h, use EXIT_REASON_PENDING_VIRT_INTR xenalyze: sync with vmx.h, use EXIT_REASON_VMXOFF xenalyze: sync with vmx.h, use EXIT_REASON_VMXON

[libvirt test] 181066: tolerable all pass - PUSHED

flight 181066 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/181066/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 181023 test-armhf-armhf-libvirt 16

Re: [PATCH v3 25/34] m68k: Convert various functions to use ptdescs

-functions/20230601-053454 base: next-20230531 patch link: https://lore.kernel.org/r/20230531213032.25338-26-vishal.moola%40gmail.com patch subject: [PATCH v3 25/34] m68k: Convert various functions to use ptdescs config: m68k-randconfig-r002-20230531 (https://download.01.org/0day-ci/archive

Re: [PATCH 2/2] x86/vPIT: account for "counter stopped" time

On 01.06.2023 13:48, Roger Pau Monné wrote: > On Tue, May 30, 2023 at 05:30:40PM +0200, Jan Beulich wrote: >> TBD: "gate" can only ever be low for chan2 (with "x86/vPIT: check/bound >> values loaded from state save record" [2] in place), so in >> principle we could get away without a new

Re: [PATCH 1/2] x86/vPIT: re-order functions

On 01.06.2023 13:50, Roger Pau Monné wrote: > On Thu, Jun 01, 2023 at 11:56:12AM +0200, Jan Beulich wrote: >> On 01.06.2023 11:17, Roger Pau Monné wrote: >>> On Tue, May 30, 2023 at 05:30:02PM +0200, Jan Beulich wrote: To avoid the need for a forward declaration of pit_load_count() in a

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

On Thu, Jun 01, 2023 at 10:19:01AM +0200, Juergen Gross wrote: > Patch 2 wants this diff on top: Obviously. :-) That fixes it, thx. Now lemme restart testing. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

[linux-linus test] 181063: regressions - FAIL

flight 181063 linux-linus real [real] flight 181077 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181063/ http://logs.test-lab.xenproject.org/osstest/logs/181077/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH v3 03/34] s390: Use pt_frag_refcount for pagetables

On Wed, 31 May 2023 14:30:01 -0700 "Vishal Moola (Oracle)" wrote: > s390 currently uses _refcount to identify fragmented page tables. > The page table struct already has a member pt_frag_refcount used by > powerpc, so have s390 use that instead of the _refcount field as well. > This improves

Re: [PATCH] MAINTAINERS: remove xenstore related files from LIBS

On Thu, Jun 01, 2023 at 12:57:56PM +0200, Jan Beulich wrote: > On 22.05.2023 18:00, Juergen Gross wrote: > > There is no need to have the Xenstore headers listed in the LIBS > > section now that they have been added to the XENSTORE section. > > > > Suggested-by: Jan Beulich > > Signed-off-by:

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

On 31.05.23 19:48, Borislav Petkov wrote: On Wed, May 31, 2023 at 04:20:08PM +0200, Juergen Gross wrote: One other note: why does mtrr_cleanup() think that using 8 instead of 6 variable MTRRs would be an "optimal setting"? Maybe the more extensive debug output below would help answer that...

[ovmf test] 181076: all pass - PUSHED

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

[PATCH v3 3/3] cmdline: parse multiple instances of the vga option

Parse all instances of the vga= option on the command line, in order to always enforce the last selection on the command line. Note that it's not safe to parse just the last occurrence of the vga= option, as then a command line with `vga=current vga=keep` would result in current being ignored.

[PATCH v3 2/3] multiboot2: do not set StdOut mode unconditionally

Only initialize StdOut if the current StdOut mode is unusable. This avoids forcefully switching StdOut to the maximum supported resolution, and thus very likely changing the GOP mode without having first parsed the command line options. Signed-off-by: Roger Pau Monné --- The code is very

[PATCH v3 1/3] multiboot2: parse vga= option when setting GOP mode

Introduce support for passing the command line to the efi_multiboot2() helper, and parse the vga= option if present. Add support for the 'gfx' and 'current' vga options, ignore the 'keep' option, and print a warning message about other options not being currently implemented. Signed-off-by:

[PATCH v3 0/3] x86/gfx: early boot improvements

Hello, The following series contains some fixes and improvements related to graphics usage when booting Xen. Proposed patches fix some shortcomings when using multiboot2, like the ignoring of the vga= parameter and forcefully switching the console to the maximum supported resolution. Thanks,

Re: [PATCH v3 0/6] block: add blk_io_plug_call() API

On Tue, May 30, 2023 at 02:09:53PM -0400, Stefan Hajnoczi wrote: > v3 > - Patch 5: Mention why dev_max_batch condition was dropped [Stefano] > v2 > - Patch 1: "is not be freed" -> "is not freed" [Eric] > - Patch 2: Remove unused nvme_process_completion_queue_plugged trace event > [Stefano] > -

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

On 01.06.23 14:48, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 08:39:17AM +0200, Juergen Gross wrote: Does this translate to: "we should remove that cleanup crap"? I'd be positive to that. :-) Why, what's wrong with that thing? Why do you need it if you don't think adding MTRRs

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

On Thu, Jun 01, 2023 at 08:39:17AM +0200, Juergen Gross wrote: > Does this translate to: "we should remove that cleanup crap"? I'd be > positive to that. :-) Why, what's wrong with that thing? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] xen/arm: debug-pl011: Use 32-bit accessors for broader compatibility

On 01/06/2023 14:17, Julien Grall wrote: > > > > > > On Thu, 1 Jun 2023 at 13:48, Michal Orzel > wrote: > > Hi Julien, > > On 01/06/2023 13:12, Julien Grall wrote: > >        > > > > > > Hi, > > > > Sorry for the

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

flight 181074 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/181074/ 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

Re: [PATCH] xen/arm: debug-pl011: Use 32-bit accessors for broader compatibility

On Thu, 1 Jun 2023 at 13:48, Michal Orzel wrote: > Hi Julien, > > On 01/06/2023 13:12, Julien Grall wrote: > > > > > > > > Hi, > > > > Sorry for the formatting. > > > > On Thu, 1 Jun 2023 at 12:31, Michal Orzel michal.or...@amd.com>> wrote: > > > > Hi Bertrand, > > > > On 01/06/2023

Re: Ping: [PATCH v2 2/2] build: use $(dot-target)

Hi Jan, > On 1 Jun 2023, at 12:52, Jan Beulich wrote: > > On 08.05.2023 14:58, Jan Beulich wrote: >> While slightly longer, I agree with Andrew that using it helps >> readability. Where touching them anyway, also wrap some overly long >> lines. >> >> Suggested-by: Andrew Cooper >>

[xen-unstable test] 181061: regressions - FAIL

flight 181061 xen-unstable real [real] flight 181071 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181061/ http://logs.test-lab.xenproject.org/osstest/logs/181071/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH 1/2] x86/vPIT: re-order functions

On Thu, Jun 01, 2023 at 11:56:12AM +0200, Jan Beulich wrote: > On 01.06.2023 11:17, Roger Pau Monné wrote: > > On Tue, May 30, 2023 at 05:30:02PM +0200, Jan Beulich wrote: > >> To avoid the need for a forward declaration of pit_load_count() in a > >> subsequent change, move it earlier in the file

  1   2   >