Re: [PATCH 06/26] loop: also use the default block size from an underlying block device

On Tue, Jun 11, 2024 at 02:58:56PM +0900, Damien Le Moal wrote: > > + if (S_ISBLK(inode->i_mode)) > > + backing_bdev = I_BDEV(inode); > > + else if (inode->i_sb->s_bdev) > > + backing_bdev = inode->i_sb->s_bdev; > > + > > Why not move this hunk inside the below "if" ?

Re: [PATCH 05/26] loop: regularize upgrading the lock size for direct I/O

On Tue, Jun 11, 2024 at 02:56:59PM +0900, Damien Le Moal wrote: > > + if (!bsize) > > + bsize = loop_default_blocksize(lo, inode->i_sb->s_bdev); > > If bsize is specified and there is a backing dev used with direct IO, should > it > be checked that bsize is a multiple of

Re: [PATCH 06/26] loop: also use the default block size from an underlying block device

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Fix the code in loop_reconfigure_limits to pick a default block size for > O_DIRECT file descriptors to also work when the loop device sits on top > of a block device and not just on a regular file on a block device based > file system. > >

Re: [PATCH 05/26] loop: regularize upgrading the lock size for direct I/O

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > The LOOP_CONFIGURE path automatically upgrades the block size to that > of the underlying file for O_DIRECT file descriptors, but the > LOOP_SET_BLOCK_SIZE path does not. Fix this by lifting the code to > pick the block size into common code.

Re: [PATCH 03/26] loop: stop using loop_reconfigure_limits in __loop_clr_fd

On Tue, Jun 11, 2024 at 02:53:19PM +0900, Damien Le Moal wrote: > > + /* reset the block size to the default */ > > + lim = queue_limits_start_update(lo->lo_queue); > > + lim.logical_block_size = 512; > > Nit: SECTOR_SIZE ? maybe ? Yes. I was following the existing code, but SECTOR_SIZE

Re: [PATCH 04/26] loop: always update discard settings in loop_reconfigure_limits

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Simplify loop_reconfigure_limits by always updating the discard limits. > This adds a little more work to loop_set_block_size, but doesn't change > the outcome as the discard flag won't change. > > Signed-off-by: Christoph Hellwig Looks OK to me.

Re: [PATCH 02/26] sd: move zone limits setup out of sd_read_block_characteristics

On Tue, Jun 11, 2024 at 07:52:39AM +0200, Christoph Hellwig wrote: > > Maybe we should clear the other zone related limits here ? If the drive is > > reformatted/converted from SMR to CMR (FORMAT WITH PRESET), the other zone > > limits may be set already, no ? > > blk_validate_zoned_limits

Re: [PATCH 03/26] loop: stop using loop_reconfigure_limits in __loop_clr_fd

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > __loop_clr_fd wants to clear all settings on the device. Prepare for > moving more settings into the block limits by open coding > loop_reconfigure_limits. > > Signed-off-by: Christoph Hellwig > --- > drivers/block/loop.c | 10 +- > 1 file

Re: [PATCH 02/26] sd: move zone limits setup out of sd_read_block_characteristics

On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote: > > - if (lim->zoned) > > + if (sdkp->device->type == TYPE_ZBC) > > Nit: use sd_is_zoned() here ? Yes. > > - if (!sd_is_zoned(sdkp)) > > + if (!sd_is_zoned(sdkp)) { > > + lim->zoned = false; > > Maybe we should

Re: [PATCH 02/26] sd: move zone limits setup out of sd_read_block_characteristics

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move a bit of code that sets up the zone flag and the write granularity > into sd_zbc_read_zones to be with the rest of the zoned limits. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/sd.c | 21 + >

Re: [PATCH 01/26] sd: fix sd_is_zoned

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Since commit 7437bb73f087 ("block: remove support for the host aware zone > model"), only ZBC devices expose a zoned access model. sd_is_zoned is > used to check for that and thus return false for host aware devices. > > Fixes: 7437bb73f087 ("block:

[PATCH 16/26] block: move the io_stat flag setting to queue_limits

Move the io_stat flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Simplify md and dm to set the flag unconditionally instead of avoiding setting a simple flag for cases where it already is set by other means, which is a bit

[PATCH 12/26] block: remove blk_flush_policy

Fold blk_flush_policy into the only caller to prepare for pending changes to it. Signed-off-by: Christoph Hellwig --- block/blk-flush.c | 33 +++-- 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/block/blk-flush.c b/block/blk-flush.c index

[PATCH 24/26] block: move the pci_p2pdma flag to queue_limits

Move the pci_p2pdma flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c | 1 - drivers/nvme/host/core.c | 8 +++- include/linux/blkdev.h | 7 --- 3 files

[PATCH 14/26] block: move the nonrot flag to queue_limits

Move the norot flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Use the chance to switch to defaulting to non-rotational and require the driver to opt into rotational, which matches the polarity of the sysfs interface. For

[PATCH 21/26] block: move the poll flag to queue_limits

Move the poll flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Stacking drivers are simplified in that they now can simply set the flag, and blk_stack_limits will clear it when the features is not supported by any of the

[PATCH 17/26] block: move the stable_write flag to queue_limits

Move the io_stat flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. The flag is now inherited by blk_stack_limits, which greatly simplifies the code in dm, and fixed md which previously did not pass on the flag set on lower

[PATCH 23/26] block: move the zone_resetall flag to queue_limits

Move the zone_resetall flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c | 1 - drivers/block/null_blk/zoned.c | 3 +-- drivers/block/ublk_drv.c | 4

[PATCH 26/26] block: move the bounce flag into the feature field

Move the bounce field into the flags field to reclaim a little bit of space. Signed-off-by: Christoph Hellwig --- block/blk-settings.c| 1 - block/blk.h | 2 +- drivers/scsi/scsi_lib.c | 2 +- include/linux/blkdev.h | 6 -- 4 files changed, 6 insertions(+), 5 deletions(-)

[PATCH 10/26] xen-blkfront: don't disable cache flushes when they fail

blkfront always had a robust negotiation protocol for detecting a write cache. Stop simply disabling cache flushes when they fail as that is a grave error. Signed-off-by: Christoph Hellwig --- drivers/block/xen-blkfront.c | 29 + 1 file changed, 9 insertions(+), 20

[PATCH 19/26] block: move the nowait flag to queue_limits

Move the nowait flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Stacking drivers are simplified in that they now can simply set the flag, and blk_stack_limits will clear it when the features is not supported by any of the

[PATCH 18/26] block: move the synchronous flag to queue_limits

Move the synchronous flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c| 1 - drivers/block/brd.c | 2 +- drivers/block/zram/zram_drv.c | 4 ++--

[PATCH 07/26] loop: fold loop_update_rotational into loop_reconfigure_limits

This prepares for moving the rotational flag into the queue_limits and also fixes it for the case where the loop device is backed by a block device. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 23 --- 1 file changed, 4 insertions(+), 19 deletions(-) diff

[PATCH 22/26] block: move the zoned flag into the feature field

Move the boolean zoned field into the flags field to reclaim a little bit of space. Signed-off-by: Christoph Hellwig --- block/blk-settings.c | 5 ++--- drivers/block/null_blk/zoned.c | 2 +- drivers/block/ublk_drv.c | 2 +- drivers/block/virtio_blk.c | 5 +++--

[PATCH 25/26] block: move the skip_tagset_quiesce flag to queue_limits

Move the skip_tagset_quiesce flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c | 1 - drivers/nvme/host/core.c | 8 +--- include/linux/blkdev.h | 6 -- 3

[PATCH 15/26] block: move the add_random flag to queue_limits

Move the add_random flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Note that this also removes code from dm to clear the flag based on the underlying devices, which can't be reached as dm devices will always start out

[PATCH 13/26] block: move cache control settings out of queue->flags

Move the cache control settings into the queue_limits so that they can be set atomically and all I/O is frozen when changing the flags. Add new features and flags field for the driver set flags, and internal (usually sysfs-controlled) flags in the block layer. Note that we'll eventually remove

[PATCH 20/26] block: move the dax flag to queue_limits

Move the dax flag into the queue_limits feature field so that it can be set atomically and all I/O is frozen when changing the flag. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c | 1 - drivers/md/dm-table.c| 4 ++-- drivers/nvdimm/pmem.c| 7 ++-

[PATCH 11/26] block: freeze the queue in queue_attr_store

queue_attr_store updates attributes used to control generating I/O, and can cause malformed bios if changed with I/O in flight. Freeze the queue in common code instead of adding it to almost every attribute. Signed-off-by: Christoph Hellwig --- block/blk-mq.c| 5 +++-- block/blk-sysfs.c |

[PATCH 01/26] sd: fix sd_is_zoned

Since commit 7437bb73f087 ("block: remove support for the host aware zone model"), only ZBC devices expose a zoned access model. sd_is_zoned is used to check for that and thus return false for host aware devices. Fixes: 7437bb73f087 ("block: remove support for the host aware zone model")

[PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode

virtblk_update_cache_mode boils down to a single call to blk_queue_write_cache. Remove it in preparation for moving the cache control flags into the queue_limits. Signed-off-by: Christoph Hellwig --- drivers/block/virtio_blk.c | 13 +++-- 1 file changed, 3 insertions(+), 10

[PATCH 05/26] loop: regularize upgrading the lock size for direct I/O

The LOOP_CONFIGURE path automatically upgrades the block size to that of the underlying file for O_DIRECT file descriptors, but the LOOP_SET_BLOCK_SIZE path does not. Fix this by lifting the code to pick the block size into common code. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c

[PATCH 03/26] loop: stop using loop_reconfigure_limits in __loop_clr_fd

__loop_clr_fd wants to clear all settings on the device. Prepare for moving more settings into the block limits by open coding loop_reconfigure_limits. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH 09/26] nbd: move setting the cache control flags to __nbd_set_size

Move setting the cache control flags in nbd in preparation for moving these flags into the queue_limits structure. Signed-off-by: Christoph Hellwig --- drivers/block/nbd.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/block/nbd.c

[PATCH 06/26] loop: also use the default block size from an underlying block device

Fix the code in loop_reconfigure_limits to pick a default block size for O_DIRECT file descriptors to also work when the loop device sits on top of a block device and not just on a regular file on a block device based file system. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 8

[PATCH 04/26] loop: always update discard settings in loop_reconfigure_limits

Simplify loop_reconfigure_limits by always updating the discard limits. This adds a little more work to loop_set_block_size, but doesn't change the outcome as the discard flag won't change. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 10 -- 1 file changed, 4

[PATCH 02/26] sd: move zone limits setup out of sd_read_block_characteristics

Move a bit of code that sets up the zone flag and the write granularity into sd_zbc_read_zones to be with the rest of the zoned limits. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 21 + drivers/scsi/sd_zbc.c | 13 - 2 files changed, 13

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

flight 186305 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186305/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186299

Re: [PATCH] MAINTAINERS: alter EFI section

On Mon, Jun 10, 2024 at 08:38:45AM +0200, Jan Beulich wrote: > To get past the recurring friction on the approach to take wrt > workarounds needed for various firmware flaws, I'm stepping down as the > maintainer of our code interfacing with EFI firmware. Two new > maintainers are being introduced

Re: [PATCH for-4.19 v1] automation: add a test for HVM domU on PVH dom0

On 10/06/2024 7:47 pm, Marek Marczykowski-Górecki wrote: > On Mon, Jun 10, 2024 at 04:25:01PM +0100, Andrew Cooper wrote: >> On 10/06/2024 2:32 pm, Marek Marczykowski-Górecki wrote: >>> This tests if QEMU works in PVH dom0. QEMU in dom0 requires enabling TUN >>> in the kernel, so do that too. >>>

Re: [XEN PATCH v6 0/7] FF-A notifications

Hi Bertrand, On 10/06/2024 16:54, Bertrand Marquis wrote: Hi Jens, On 10 Jun 2024, at 08:53, Jens Wiklander wrote: Hi, This patch set adds support for FF-A notifications. We only support global notifications, per vCPU notifications remain unsupported. The first three patches are further

Re: [PATCH for-4.19 v1] automation: add a test for HVM domU on PVH dom0

On Mon, Jun 10, 2024 at 04:25:01PM +0100, Andrew Cooper wrote: > On 10/06/2024 2:32 pm, Marek Marczykowski-Górecki wrote: > > This tests if QEMU works in PVH dom0. QEMU in dom0 requires enabling TUN > > in the kernel, so do that too. > > > > Add it to both x86 runners, similar to the PVH domU

[linux-linus test] 186303: tolerable FAIL - PUSHED

flight 186303 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/186303/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 8 xen-boot fail in 186298 pass in 186303 test-armhf-armhf-examine 8

[ovmf test] 186306: all pass - PUSHED

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

[PATCH for-4.19? v6 5/9] docs/man: Add altp2m_count parameter to the xl.cfg manual

From: Petr Beneš Update manual pages to include detailed information about the altp2m_count configuration parameter. Signed-off-by: Petr Beneš --- docs/man/xl.cfg.5.pod.in | 14 ++ 1 file changed, 14 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in

[PATCH for-4.19? v6 3/9] xen: Refactor altp2m options into a structured format

From: Petr Beneš Encapsulate the altp2m options within a struct. This change is preparatory and sets the groundwork for introducing additional parameter in subsequent commit. Signed-off-by: Petr Beneš Acked-by: Julien Grall # arm Reviewed-by: Jan Beulich # hypervisor ---

[PATCH for-4.19? v6 7/9] tools/libxl: Activate the altp2m_count feature

From: Petr Beneš This commit activates the previously introduced altp2m_count parameter, establishing the connection between libxl and Xen. Signed-off-by: Petr Beneš --- tools/libs/light/libxl_create.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/libs/light/libxl_create.c

[PATCH for-4.19? v6 1/9] tools/ocaml: Fix mixed tabs/spaces

From: Petr Beneš No functional change. Signed-off-by: Petr Beneš Acked-by: Christian Lindig --- tools/ocaml/libs/xc/xenctrl_stubs.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c

[PATCH for-4.19? v6 9/9] tools/ocaml: Add altp2m_count parameter

From: Petr Beneš Allow developers using the OCaml bindings to set the altp2m_count parameter. Signed-off-by: Petr Beneš Acked-by: Christian Lindig --- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/ocaml/libs/xc/xenctrl_stubs.c | 19

[PATCH for-4.19? v6 6/9] xen: Make the maximum number of altp2m views configurable for x86

From: Petr Beneš This commit introduces the ability to configure the maximum number of altp2m views for the domain during its creation. Previously, the limits were hardcoded to a maximum of 10. This change allows for greater flexibility in environments that require more or fewer altp2m views.

[PATCH for-4.19? v6 8/9] xen/x86: Disallow creating domains with altp2m enabled and altp2m.nr == 0

From: Petr Beneš Since libxl finally sends the altp2m.nr value, we can remove the previously introduced temporary workaround. Creating domain with enabled altp2m while setting altp2m.nr == 0 doesn't make sense and it's probably not what user wants. Signed-off-by: Petr Beneš Acked-by: Jan

[PATCH for-4.19? v6 0/9] x86: Make MAX_ALTP2M configurable

From: Petr Beneš This series introduces the ability to configure the maximum number of altp2m tables during domain creation. Previously, the limits were hardcoded to a maximum of 10. This change allows for greater flexibility in environments that require more or fewer altp2m views. This

[PATCH for-4.19? v6 2/9] tools/ocaml: Add missing ocaml bindings for altp2m_opts

From: Petr Beneš Fixes: 0291089f6ea8 ("xen: enable altp2m at create domain domctl") Signed-off-by: Petr Beneš Acked-by: Christian Lindig --- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/ocaml/libs/xc/xenctrl_stubs.c | 9 ++--- 3 files

[PATCH for-4.19? v6 4/9] tools/xl: Add altp2m_count parameter

From: Petr Beneš Introduce a new altp2m_count parameter to control the maximum number of altp2m views a domain can use. By default, if altp2m_count is unspecified and altp2m is enabled, the value is set to 10, reflecting the legacy behavior. This change is preparatory; it establishes the

Re: [XEN PATCH v1] x86/intel: optional build of TSX support

On 06/06/2024 12:04 pm, Sergiy Kibrik wrote: > Transactional Synchronization Extensions are available for certain Intel's > CPUs only, hence can be put under CONFIG_INTEL build option. Careful with "available" vs "supported". They're only supported on certain Intel CPUs, but suffice it to say

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

flight 186304 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186304/ 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: [XEN PATCH v9 0/5] Support device passthrough when dom0 is PVH on Xen

On 07.06.2024 10:11, Jiqian Chen wrote: > Hi All, > This is v9 series to support passthrough when dom0 is PVH > v8->v9 changes: > * patch#1: Move pcidevs_unlock below write_lock, and remove > "ASSERT(pcidevs_locked());" from vpci_reset_device_state; >Add pci_device_state_reset_type to

Re: [XEN PATCH v9 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 07.06.2024 10:11, Jiqian Chen wrote: > On PVH dom0, the gsis don't get registered, but > the gsi of a passthrough device must be configured for it to > be able to be mapped into a hvm domU. > On Linux kernel side, it calles PHYSDEVOP_setup_gsi for > passthrough devices to register gsi when dom0

Re: [XEN PATCH v9 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH

On 07.06.2024 10:11, Jiqian Chen wrote: > If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for > a passthrough device by using gsi, see qemu code > xen_pt_realize->xc_physdev_map_pirq and libxl code > pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq > will call into Xen,

Re: [PATCH for-4.19 v2] x86/pvh: declare PVH dom0 supported with caveats

On Mon, Jun 10, 2024 at 9:50 AM Roger Pau Monne wrote: > > PVH dom0 is functionally very similar to PVH domU except for the domain > builder and the added set of hypercalls available to it. > > The main concern with declaring it "Supported" is the lack of some features > when compared to classic

Re: [XEN PATCH v6 0/7] FF-A notifications

Hi Jens, > On 10 Jun 2024, at 08:53, Jens Wiklander wrote: > > Hi, > > This patch set adds support for FF-A notifications. We only support > global notifications, per vCPU notifications remain unsupported. > > The first three patches are further cleanup and can be merged before the > rest if

Re: [XEN PATCH v6 7/7] xen/arm: ffa: support notification

Hi Jens, > On 10 Jun 2024, at 08:53, Jens Wiklander wrote: > > Add support for FF-A notifications, currently limited to an SP (Secure > Partition) sending an asynchronous notification to a guest. > > Guests and Xen itself are made aware of pending notifications with an > interrupt. The

Re: [XEN PATCH v1] x86/intel: optional build of TSX support

On 06.06.2024 13:04, Sergiy Kibrik wrote: > --- a/xen/arch/x86/spec_ctrl.c > +++ b/xen/arch/x86/spec_ctrl.c > @@ -116,8 +116,10 @@ static int __init cf_check parse_spec_ctrl(const char *s) > if ( opt_pv_l1tf_domu < 0 ) > opt_pv_l1tf_domu = 0; > > +#ifdef

Re: [PATCH] MAINTAINERS: add me as scheduer maintainer

On Thu, Jun 6, 2024 at 6:48 AM Juergen Gross wrote: > > I've been active in the scheduling code since many years now. Add > me as a maintainer. > > Signed-off-by: Juergen Gross > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index

Re: [XEN PATCH v1] x86/intel: optional build of PSR support

On 06.06.2024 10:39, Sergiy Kibrik wrote: > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -1160,6 +1160,7 @@ long arch_do_domctl( > break; > } > > +#ifdef CONFIG_INTEL > case XEN_DOMCTL_psr_cmt_op: > if ( !psr_cmt_enabled() ) > { > @@ -1262,6

Re: [PATCH for-4.19 v1] automation: add a test for HVM domU on PVH dom0

On 10/06/2024 2:32 pm, Marek Marczykowski-Górecki wrote: > This tests if QEMU works in PVH dom0. QEMU in dom0 requires enabling TUN > in the kernel, so do that too. > > Add it to both x86 runners, similar to the PVH domU test. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Andrew Cooper

Re: [XEN PATCH v3 15/16] x86/vmx: replace CONFIG_HVM with CONFIG_VMX in vmx.h

On 03.06.2024 13:36, Sergiy Kibrik wrote: > As now we got a separate config option for VMX which itself depends on > CONFIG_HVM, we need to use it to provide vmx_pi_hooks_{assign,deassign} > stubs for case when VMX is disabled while HVM is enabled. > > Signed-off-by: Sergiy Kibrik Acked-by: Jan

Re: [XEN PATCH v3 13/16] x86/vpmu: guard calls to vmx/svm functions

On 03.06.2024 13:32, Sergiy Kibrik wrote: > If VMX/SVM disabled in the build, we may still want to have vPMU drivers for > PV guests. Yet in such case before using VMX/SVM features and functions we > have > to explicitly check if they're available in the build. For this puspose Nit: It's not the

Re: [XEN PATCH v3 12/16] x86/vmx: guard access to cpu_has_vmx_* in common code

On 03.06.2024 13:30, Sergiy Kibrik wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -5197,7 +5197,7 @@ int hvm_debug_op(struct vcpu *v, int32_t op) > { > case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON: > case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF: > -

Re: [XEN PATCH v3 10/16] x86/domain: guard svm specific functions with usinc_svm macro

On 03.06.2024 13:26, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > Replace cpu_has_svm check with using_svm, so that not only SVM support in CPU > gets checked, but also presence of functions svm_load_segs() and > svm_load_segs_prefetch() in the build checked as well. > > Since SVM depends

Re: [PATCH for-4.19? v5 07/10] xen: Make the maximum number of altp2m views configurable for x86

On 10.06.2024 14:21, Petr Beneš wrote: > On Mon, Jun 10, 2024 at 1:21 PM Jan Beulich wrote: >> >> On 10.06.2024 12:34, Petr Beneš wrote: >>> On Mon, Jun 10, 2024 at 12:16 PM Jan Beulich wrote: On 10.06.2024 11:10, Petr Beneš wrote: > On Mon, Jun 10, 2024 at 9:30 AM Jan Beulich

Re: [PATCH for-4.19] x86/EPT: relax iPAT for "invalid" MFNs

On 10.06.2024 16:58, Jan Beulich wrote: > mfn_valid() is RAM-focused; it will often return false for MMIO. Yet > access to actual MMIO space should not generally be restricted to UC > only; especially video frame buffer accesses are unduly affected by such > a restriction. Permit PAT use for

[PATCH] x86/EPT: relax iPAT for "invalid" MFNs

mfn_valid() is RAM-focused; it will often return false for MMIO. Yet access to actual MMIO space should not generally be restricted to UC only; especially video frame buffer accesses are unduly affected by such a restriction. Permit PAT use for directly assigned MMIO as long as the domain is known

[PATCH v2 5/7] x86/irq: deal with old_cpu_mask for interrupts in movement in fixup_irqs()

Given the current logic it's possible for ->arch.old_cpu_mask to get out of sync: if a CPU set in old_cpu_mask is offlined and then onlined again without old_cpu_mask having been updated the data in the mask will no longer be accurate, as when brought back online the CPU will no longer have

[PATCH v2 7/7] x86/irq: forward pending interrupts to new destination in fixup_irqs()

fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given the CPU is to become offline, the normal migration logic used by Xen where the vector in the previous target(s) is left configured until the interrupt is received on the new destination is not suitable. Instead attempt

[PATCH v2 6/7] x86/irq: handle moving interrupts in _assign_irq_vector()

Currently there's logic in fixup_irqs() that attempts to prevent _assign_irq_vector() from failing, as fixup_irqs() is required to evacuate all interrupts from the CPUs not present in the input mask. The current logic in fixup_irqs() is incomplete, as it doesn't deal with interrupts that have

[PATCH v2 3/7] x86/irq: limit interrupt movement done by fixup_irqs()

The current check used in fixup_irqs() to decide whether to move around interrupts is based on the affinity mask, but such mask can have all bits set, and hence is unlikely to be a subset of the input mask. For example if an interrupt has an affinity mask of all 1s, any input to fixup_irqs()

[PATCH v2 1/7] x86/smp: do not use shorthand IPI destinations in CPU hot{,un}plug contexts

Due to the current rwlock logic, if the CPU calling get_cpu_maps() does so from a cpu_hotplug_{begin,done}() region the function will still return success, because a CPU taking the rwlock in read mode after having taken it in write mode is allowed. Such behavior however defeats the purpose of

[PATCH v2 4/7] x86/irq: restrict CPU movement in set_desc_affinity()

If external interrupts are using logical mode it's possible to have an overlap between the current ->arch.cpu_mask and the provided mask (or TARGET_CPUS). If that's the case avoid assigning a new vector and just move the interrupt to a member of ->arch.cpu_mask that overlaps with the provided

[PATCH v2 0/7] x86/irq: fixes for CPU hot{,un}plug

Hello, The following series aim to fix interrupt handling when doing CPU plug/unplug operations. Without this series running: cpus=`xl info max_cpu_id` while [ 1 ]; do for i in `seq 1 $cpus`; do xen-hptool cpu-offline $i; xen-hptool cpu-online $i; done done Quite

[PATCH v2 2/7] x86/irq: describe how the interrupt CPU movement works

The logic to move interrupts across CPUs is complex, attempt to provide a comment that describes the expected behavior so users of the interrupt system have more context about the usage of the arch_irq_desc structure fields. Signed-off-by: Roger Pau Monné --- Changes since v1: - Mention the

[PATCH RFC] Arm64: amend "xen/arm64: head: Add missing code symbol annotations"

While the change[1] didn't go in yet, there is the intention for the ELF metadata annotations from xen/linkage.h to also effect honoring of CONFIG_CC_SPLIT_SECTIONS. In code that's placement / ordering sensitive, these annotations therefore need using with some care. [1]

[PATCH v1] automation: add a test for HVM domU on PVH dom0

This tests if QEMU works in PVH dom0. QEMU in dom0 requires enabling TUN in the kernel, so do that too. Add it to both x86 runners, similar to the PVH domU test. Signed-off-by: Marek Marczykowski-Górecki --- Requires rebuilding test-artifacts/kernel/6.1.19 I'm actually not sure if there is a

Re: [PATCH for-4.19? v5 07/10] xen: Make the maximum number of altp2m views configurable for x86

> (when booted with altp2m=1) Sorry, forgot to remove this statement before sending the email, it's not really true. I wanted to add that as I wrote in a previous email exchange - altp2m should be ideally initialized only when it's requested - as opposed to the current situation, when it's

Re: [PATCH for-4.19? v5 07/10] xen: Make the maximum number of altp2m views configurable for x86

On Mon, Jun 10, 2024 at 1:21 PM Jan Beulich wrote: > > On 10.06.2024 12:34, Petr Beneš wrote: > > On Mon, Jun 10, 2024 at 12:16 PM Jan Beulich wrote: > >> > >> On 10.06.2024 11:10, Petr Beneš wrote: > >>> On Mon, Jun 10, 2024 at 9:30 AM Jan Beulich wrote: > > On 09.06.2024 01:06, Petr

[xen-unstable test] 186299: tolerable FAIL

flight 186299 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186299/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186293

Re: [XEN PATCH v3 09/16] x86/traps: guard vmx specific functions with usinc_vmx macro

On 03.06.2024 13:24, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > Replace cpu_has_vmx check with using_vmx, so that not only VMX support in CPU > gets checked, but also presence of functions vmx_vmcs_enter() & > vmx_vmcs_exit() > in the build checked as well. > > Also since CONFIG_VMX is

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

flight 186301 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186301/ 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: [XEN PATCH v3 01/16] x86: introduce AMD-V and Intel VT-x Kconfig options

On 03.06.2024 13:07, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > Introduce two new Kconfig options, SVM and VMX, to allow code > specific to each virtualization technology to be separated and, when not > required, stripped. > CONFIG_SVM will be used to enable virtual machine extensions on

Re: [XEN PATCH v3 05/16] x86: introduce using_{svm,vmx} macros

On 03.06.2024 13:16, Sergiy Kibrik wrote: > --- a/xen/arch/x86/include/asm/hvm/hvm.h > +++ b/xen/arch/x86/include/asm/hvm/hvm.h > @@ -26,6 +26,9 @@ extern bool opt_hvm_fep; > #define opt_hvm_fep 0 > #endif > > +#define using_vmx ( IS_ENABLED(CONFIG_VMX) && cpu_has_vmx ) > +#define using_svm (

Re: [PATCH v1 1/3] mm: pass meminit_context to __free_pages_core()

On Mon, Jun 10, 2024 at 10:38:05AM +0200, David Hildenbrand wrote: > On 10.06.24 06:03, Oscar Salvador wrote: > > On Fri, Jun 07, 2024 at 11:09:36AM +0200, David Hildenbrand wrote: > > > In preparation for further changes, let's teach __free_pages_core() > > > about the differences of memory

Re: [XEN PATCH v3 08/16] x86/p2m: guard EPT functions with using_vmx macro

On 03.06.2024 13:22, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > Replace cpu_has_vmx check with using_vmx, so that presence of functions > ept_p2m_init() and ept_p2m_uninit() in the build gets checked. > Since currently Intel EPT implementation depends on CONFIG_VMX config option, > when

Re: vcpumask_to_pcpumask() case study

On 10.06.2024 12:12, Andrew Cooper wrote: > On 10/06/2024 8:15 am, Jan Beulich wrote: >> On 07.06.2024 14:35, Andrew Cooper wrote: >>> On 03/06/2024 10:19 pm, Jan Beulich wrote: On 01.06.2024 20:50, Andrew Cooper wrote: > One of the followon items I had from the bitops clean-up is this:

Re: [PATCH v12 8/8] xen/README: add compiler and binutils versions for RISC-V64

On Thu, 2024-05-30 at 20:52 +0100, Andrew Cooper wrote: > On 29/05/2024 8:55 pm, Oleksii Kurochko wrote: > > diff --git a/README b/README > > index c8a108449e..30da5ff9c0 100644 > > --- a/README > > +++ b/README > > @@ -48,6 +48,10 @@ provided by your OS distributor: > >    - For ARM 64-bit: >

Re: [PATCH] MAINTAINERS: add me as scheduer maintainer

George, Dario, On 06.06.2024 07:47, Juergen Gross wrote: > I've been active in the scheduling code since many years now. Add > me as a maintainer. > > Signed-off-by: Juergen Gross > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index

Re: [XEN PATCH v3 04/16] x86: introduce CONFIG_ALTP2M Kconfig option

On 10.06.2024 12:48, Sergiy Kibrik wrote: > 07.06.24 10:47, Jan Beulich: >> On 03.06.2024 13:13, Sergiy Kibrik wrote: >>> --- a/xen/arch/x86/include/asm/p2m.h >>> +++ b/xen/arch/x86/include/asm/p2m.h >>> @@ -577,10 +577,10 @@ static inline gfn_t mfn_to_gfn(const struct domain >>> *d, mfn_t mfn)

Re: [PATCH for-4.19? v5 07/10] xen: Make the maximum number of altp2m views configurable for x86

On 10.06.2024 12:34, Petr Beneš wrote: > On Mon, Jun 10, 2024 at 12:16 PM Jan Beulich wrote: >> >> On 10.06.2024 11:10, Petr Beneš wrote: >>> On Mon, Jun 10, 2024 at 9:30 AM Jan Beulich wrote: On 09.06.2024 01:06, Petr Beneš wrote: > On Thu, Jun 6, 2024 at 9:24 AM Jan Beulich

Re: [XEN PATCH v3 04/16] x86: introduce CONFIG_ALTP2M Kconfig option

07.06.24 10:47, Jan Beulich: On 03.06.2024 13:13, Sergiy Kibrik wrote: --- a/xen/arch/x86/include/asm/p2m.h +++ b/xen/arch/x86/include/asm/p2m.h @@ -577,10 +577,10 @@ static inline gfn_t mfn_to_gfn(const struct domain *d, mfn_t mfn) return _gfn(mfn_x(mfn)); } -#ifdef CONFIG_HVM

Re: Segment truncation in multi-segment PCI handling?

On Mon, Jun 10, 2024 at 12:11:58PM +0200, Jan Beulich wrote: > On 10.06.2024 11:46, Roger Pau Monné wrote: > > On Mon, Jun 10, 2024 at 10:41:19AM +0200, Jan Beulich wrote: > >> On 10.06.2024 10:28, Roger Pau Monné wrote: > >>> On Mon, Jun 10, 2024 at 09:58:11AM +0200, Jan Beulich wrote: > On

[ovmf test] 186302: all pass - PUSHED

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

  1   2   >