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

Hi Julien and Oleksii, @Oleksii: Could we consider having this serie merged for next release ? It is a feature that is in tech-preview at the moment and as such should not have any consequences on existing system unless it is activated explicitly in the Xen configuration. There are some change

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

Hi all, On Tue, Jun 11, 2024 at 9:09 AM Bertrand Marquis wrote: > > Hi Julien and Oleksii, > > @Oleksii: Could we consider having this serie merged for next release ? > > It is a feature that is in tech-preview at the moment and as such should not > have any > consequences on existing system unl

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

On 6/11/24 2:52 PM, Christoph Hellwig wrote: > 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)) { >>> +

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

On 6/11/24 2:54 PM, Christoph Hellwig wrote: > 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 alrea

Re: [PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Reviewed-by: Damien Le Moal -- Damien Le

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move setting the cache control flags in nbd in preparation for moving > these flags into the queue_limits structure. > > Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Looks good to me but maybe mention that removal of

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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

Re: [PATCH 12/26] block: remove blk_flush_policy

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Fold blk_flush_policy into the only caller to prepare for pending changes > to it. > > Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research

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

On Mon, Jun 10, 2024 at 04:58:52PM +0200, 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. Perm

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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 allo

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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: Roge

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

On Mon, Jun 10, 2024 at 04:55:34PM +0100, George Dunlap wrote: > 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 declari

Re: [PATCH v1 2/3] mm/memory_hotplug: initialize memmap of !ZONE_DEVICE with PageOffline() instead of PageReserved()

On Mon, Jun 10, 2024 at 10:56:02AM +0200, David Hildenbrand wrote: > There are fortunately not that many left. > > I'd even say marking them (vmemmap) reserved is more wrong than right: note > that ordinary vmemmap pages after memory hotplug are not reserved! Only > bootmem should be reserved. Ok

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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. ...so that they can be set atomically with the device queue frozen when changing the flags. may be better. >

Re: [PATCH v1 2/3] mm/memory_hotplug: initialize memmap of !ZONE_DEVICE with PageOffline() instead of PageReserved()

On Fri, Jun 07, 2024 at 11:09:37AM +0200, David Hildenbrand wrote: > We currently initialize the memmap such that PG_reserved is set and the > refcount of the page is 1. In virtio-mem code, we have to manually clear > that PG_reserved flag to make memory offlining with partially hotplugged > memory

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

On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote: > > On 10.06.2024 19:10, Petr Beneš wrote: > > 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. > > > >

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move the norot flag into the queue_limits feature field so that it can be s/norot/nonrot > set atomically and all I/O is frozen when changing the flag. and... -> with the queue frozen when... ? > > Use the chance to switch to defaulting to non-rot

Re: [PATCH v1 2/3] mm/memory_hotplug: initialize memmap of !ZONE_DEVICE with PageOffline() instead of PageReserved()

On 11.06.24 09:45, Oscar Salvador wrote: On Mon, Jun 10, 2024 at 10:56:02AM +0200, David Hildenbrand wrote: There are fortunately not that many left. I'd even say marking them (vmemmap) reserved is more wrong than right: note that ordinary vmemmap pages after memory hotplug are not reserved! On

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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. Same remark as the previous patches for the end of this sentence.c > > Note that this also removes code fro

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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. Why a feature ? It seems more appropriate for io_stat to be a flag rather than a feature as that is a block laye

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

On 6/11/24 07:19, 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: remove sup

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

On 6/11/24 07:19, 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 + drivers/scsi/sd_zbc.c | 13

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move the io_stat flag into the queue_limits feature field so that it can s/io_stat/stable_write > 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

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Looks good. Reviewed-by: Damien Le Moal -- Damien Le Moal Western

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

On 6/11/24 07:19, 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 changed, 9 ins

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

On 6/11/24 07:19, 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 --- drivers/block/loop.c |

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 i

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

On 6/11/24 07:19, 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. Signed-off-by:

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Looks good. Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital

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

On 6/11/24 07:19, 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. Signed-off-by: Christo

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

On 6/11/24 07:19, Christoph Hellwig wrote: 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 chang

Re: [PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode

On 6/11/24 07:19, Christoph Hellwig wrote: 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

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

On 6/11/24 07:19, Christoph Hellwig wrote: 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(-) Re

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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

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

On 6/11/24 07:19, Christoph Hellwig wrote: 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 +-

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

On 6/11/24 07:19, Christoph Hellwig wrote: 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 --- bloc

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move the boolean zoned field into the flags field to reclaim a little > bit of space. Nit: flags -> feature flags > > Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research

Re: [PATCH 12/26] block: remove blk_flush_policy

On 6/11/24 07:19, Christoph Hellwig wrote: 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(-) Reviewed-by: Hannes R

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Re

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Resea

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > 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 Reviewed-by: Damien Le Moal -- Damien Le Moal Western Di

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

On 11.06.2024 09:41, Roger Pau Monné wrote: > On Mon, Jun 10, 2024 at 04:58:52PM +0200, 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

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

On 6/11/24 2:19 PM, Christoph Hellwig wrote: > Move the bounce field into the flags field to reclaim a little bit of s/flags/feature > space. > > Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research

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

On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: > On 11.06.2024 09:41, Roger Pau Monné wrote: > > On Mon, Jun 10, 2024 at 04:58:52PM +0200, Jan Beulich wrote: > >> mfn_valid() is RAM-focused; it will often return false for MMIO. Yet > >> access to actual MMIO space should not generally

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

On 11.06.2024 10:00, Petr Beneš wrote: > On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote: >> >> On 10.06.2024 19:10, Petr Beneš wrote: >>> From: Petr Beneš >>> >>> Encapsulate the altp2m options within a struct. This change is preparatory >>> and sets the groundwork for introducing additional p

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

On 11.06.2024 11:02, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: >> On 11.06.2024 09:41, Roger Pau Monné wrote: >>> On Mon, Jun 10, 2024 at 04:58:52PM +0200, Jan Beulich wrote: --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @

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

On Tue, Jun 11, 2024 at 11:14 AM Jan Beulich wrote: > > On 11.06.2024 10:00, Petr Beneš wrote: > > On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote: > >> > >> On 10.06.2024 19:10, Petr Beneš wrote: > >>> From: Petr Beneš > >>> > >>> Encapsulate the altp2m options within a struct. This change is

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

On 11.06.2024 11:34, Petr Beneš wrote: > On Tue, Jun 11, 2024 at 11:14 AM Jan Beulich wrote: >> On 11.06.2024 10:00, Petr Beneš wrote: >>> On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote: On 10.06.2024 19:10, Petr Beneš wrote: > From: Petr Beneš > > Encapsulate the altp2m opti

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

On Tue, Jun 11, 2024 at 11:36 AM Jan Beulich wrote: > > On 11.06.2024 11:34, Petr Beneš wrote: > > On Tue, Jun 11, 2024 at 11:14 AM Jan Beulich wrote: > >> On 11.06.2024 10:00, Petr Beneš wrote: > >>> On Tue, Jun 11, 2024 at 8:41 AM Jan Beulich wrote: > On 10.06.2024 19:10, Petr Beneš wrote

Re: [PATCH v1 2/3] mm/memory_hotplug: initialize memmap of !ZONE_DEVICE with PageOffline() instead of PageReserved()

On 07.06.24 11:09, David Hildenbrand wrote: We currently initialize the memmap such that PG_reserved is set and the refcount of the page is 1. In virtio-mem code, we have to manually clear that PG_reserved flag to make memory offlining with partially hotplugged memory blocks possible: has_unmovab

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

On 6/11/24 07:19, Christoph Hellwig wrote: 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

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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 affi

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

On 07.06.24 11:09, David Hildenbrand wrote: In preparation for further changes, let's teach __free_pages_core() about the differences of memory hotplug handling. Move the memory hotplug specific handling from generic_online_page() to __free_pages_core(), use adjust_managed_page_count() on the me

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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

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

Hi Bertrand and Julien, On Tue, 2024-06-11 at 07:09 +, Bertrand Marquis wrote: > Hi Julien and Oleksii, > > @Oleksii: Could we consider having this serie merged for next release > ? We can consider including it in Xen 4.19 as it has a low impact on existing systems and needs to be explicitly

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

On Mon, 2024-06-10 at 16:25 +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 test. >

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

On Mon, 2024-06-10 at 17:00 +0200, Jan Beulich wrote: > 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

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Wed, May 22, 2024 at 05:39:03PM +0200, Marek Marczykowski-Górecki wrote: > In some cases, only few registers on a page needs to be write-protected. > Examples include USB3 console (64 bytes worth of registers) or MSI-X's > PBA table (which doesn't need to span the whole table either), although >

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

Looks good, Reviewed-by: Johannes Thumshirn

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Fri, Jun 07, 2024 at 09:01:25AM +0200, Jan Beulich wrote: > On 22.05.2024 17:39, Marek Marczykowski-Górecki wrote: > > --- a/xen/arch/x86/include/asm/mm.h > > +++ b/xen/arch/x86/include/asm/mm.h > > @@ -522,9 +522,34 @@ extern struct rangeset *mmio_ro_ranges; > > void memguard_guard_stack(void

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

On Tue, Jun 11, 2024 at 11:33:24AM +0200, Jan Beulich wrote: > On 11.06.2024 11:02, Roger Pau Monné wrote: > > On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: > >> On 11.06.2024 09:41, Roger Pau Monné wrote: > >>> On Mon, Jun 10, 2024 at 04:58:52PM +0200, Jan Beulich wrote: > ---

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On 11.06.2024 12:40, Roger Pau Monné wrote: > On Wed, May 22, 2024 at 05:39:03PM +0200, Marek Marczykowski-Górecki wrote: >> +int __init subpage_mmio_ro_add( >> +paddr_t start, >> +size_t size) >> +{ >> +mfn_t mfn_start = maddr_to_mfn(start); >> +paddr_t end = start + size - 1; >> +

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Tue, Jun 11, 2024 at 12:40:49PM +0200, Roger Pau Monné wrote: > On Wed, May 22, 2024 at 05:39:03PM +0200, Marek Marczykowski-Górecki wrote: > > In some cases, only few registers on a page needs to be write-protected. > > Examples include USB3 console (64 bytes worth of registers) or MSI-X's > >

[ovmf test] 186309: all pass - PUSHED

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

Re: [PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode

Looks good, Reviewed-by: Johannes Thumshirn

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

On 11.06.2024 13:08, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 11:33:24AM +0200, Jan Beulich wrote: >> On 11.06.2024 11:02, Roger Pau Monné wrote: >>> On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: On 11.06.2024 09:41, Roger Pau Monné wrote: > On Mon, Jun 10, 2024 at 0

Re: [PATCH v4 0/7] Static shared memory followup v2 - pt2

+ Oleksii > On 24 May 2024, at 13:40, Luca Fancellu wrote: > > This serie is a partial rework of this other serie: > https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/ > > The original serie is addressing an issue of the static shared memory featu

Re: [PATCH v4 0/7] Static shared memory followup v2 - pt2

Hi, On 11/06/2024 14:35, Luca Fancellu wrote: > > > + Oleksii > >> On 24 May 2024, at 13:40, Luca Fancellu wrote: >> >> This serie is a partial rework of this other serie: >> https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/ >> >> The original s

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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 bro

[xen-unstable test] 186308: tolerable FAIL

flight 186308 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186308/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvhv2-amd 20 guest-localmigrate/x10fail pass in 186307 test-amd64-amd64-qemuu-freebsd11

[PATCH for-4.19] CI: Update FreeBSD to 13.3

Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Michal Orzel CC: Roger Pau Monné CC: Oleksii Kurochko CC: Jan Beulich Updated run: https://cirrus-ci.com/task/4903594304995328 For 4.19, and for backporting to all trees including security trees. FreeBSD-13.2 isn't available any

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Tue, Jun 11, 2024 at 01:38:35PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Jun 11, 2024 at 12:40:49PM +0200, Roger Pau Monné wrote: > > On Wed, May 22, 2024 at 05:39:03PM +0200, Marek Marczykowski-Górecki wrote: > > > +if ( !entry ) > > > +{ > > > +/* iter == NULL marks i

Re: [PATCH for-4.19] CI: Update FreeBSD to 13.3

On Tue, Jun 11, 2024 at 01:47:01PM +0100, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné Albeit I'm unsure if that's some kind of glitch or error on the FreeBSD side. 13.2 is not EOL until June 30, 2024 [0]. Thanks, Roger. [0] https://www.freebsd.org/security/#

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Tue, Jun 11, 2024 at 02:55:22PM +0200, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 01:38:35PM +0200, Marek Marczykowski-Górecki wrote: > > On Tue, Jun 11, 2024 at 12:40:49PM +0200, Roger Pau Monné wrote: > > > On Wed, May 22, 2024 at 05:39:03PM +0200, Marek Marczykowski-Górecki > > > wrote

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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 incomplet

Re: [PATCH for-4.19 0/9] x86/irq: fixes for CPU hot{,un}plug

On 29.05.2024 11:37, Oleksii K. wrote: > On Wed, 2024-05-29 at 11:01 +0200, Roger Pau Monne wrote: >> 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

[ANNOUNCE] Call for agenda items - Community Call 13th June 2024

Hi all, *Please add your proposed agenda items below.* https://cryptpad.fr/pad/#/2/pad/edit/Uj1NJNpA9pgpXJJ54dyuqhDQ/ If any action items are missing or have been resolved, please add/remove them from the sheet. *CALL LINK: https://meet.jit.si/XenProjectCommunityCall

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > @@ -2589,6 +2589,28 @@ void fixup_irqs(const cpumask_t *mask, bool verbose) > affinity); > } > > +if ( desc->arch.move_in_progress && > + !cpumask_test_cpu(cpu, &cpu_online_map) && Btw - an

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

On 10.06.2024 16:20, Roger Pau Monne wrote: > 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

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

On Tue, Jun 11, 2024 at 01:52:58PM +0200, Jan Beulich wrote: > On 11.06.2024 13:08, Roger Pau Monné wrote: > > On Tue, Jun 11, 2024 at 11:33:24AM +0200, Jan Beulich wrote: > >> On 11.06.2024 11:02, Roger Pau Monné wrote: > >>> On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: > On 1

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

On 11/06/2024 10:33 am, Jan Beulich wrote: > On 11.06.2024 11:02, Roger Pau Monné wrote: >> On Tue, Jun 11, 2024 at 10:26:32AM +0200, Jan Beulich wrote: >>> On 11.06.2024 09:41, Roger Pau Monné wrote: On Mon, Jun 10, 2024 at 04:58:52PM +0200, Jan Beulich wrote: > --- a/xen/arch/x86/mm/p2m-

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Tue, Jun 11, 2024 at 03:15:42PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Jun 11, 2024 at 02:55:22PM +0200, Roger Pau Monné wrote: > > On Tue, Jun 11, 2024 at 01:38:35PM +0200, Marek Marczykowski-Górecki wrote: > > > On Tue, Jun 11, 2024 at 12:40:49PM +0200, Roger Pau Monné wrote: > > >

Re: [RFC XEN PATCH v9 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

On 07.06.2024 10:11, Jiqian Chen wrote: > Some type of domain don't have PIRQ, like PVH, it do not do > PHYSDEVOP_map_pirq for each gsi. When passthrough a device > to guest on PVH dom0, callstack > pci_add_dm_done->XEN_DOMCTL_irq_permission will failed at > domain_pirq_to_irq, because PVH has no m

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

On 11.06.2024 15:52, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 01:52:58PM +0200, Jan Beulich wrote: >> On 11.06.2024 13:08, Roger Pau Monné wrote: >>> I really wonder whether Xen has enough information to figure out >>> whether a hole (MMIO region) is supposed to be accessed as UC or >>> som

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

On 31/05/2024 7:18 am, Jan Beulich wrote: > On 30.05.2024 21:52, 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:

Re: [PATCH v4 1/2] x86/mm: add API for marking only part of a MMIO page read only

On Tue, Jun 11, 2024 at 04:07:03PM +0200, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 03:15:42PM +0200, Marek Marczykowski-Górecki wrote: > > It's location is discovered at startup > > (device presents a linked-list of capabilities in one of its BARs). > > The spec talks only about alignment o

Re: [PATCH v12 5/8] xen/riscv: add minimal stuff to mm.h to build full Xen

On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote: > On 29/05/2024 8:55 pm, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich > > This patch looks like it can go in independently?  Or does it depend > on > having bitops.h working in practice? > > However

Re: [PATCH v4 0/7] Static shared memory followup v2 - pt2

On Tue, 2024-06-11 at 12:35 +, Luca Fancellu wrote: > + Oleksii > > > On 24 May 2024, at 13:40, Luca Fancellu > > wrote: > > > > This serie is a partial rework of this other serie: > > https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/ > > > >

Re: [PATCH for-4.19] CI: Update FreeBSD to 13.3

On Tue, 2024-06-11 at 13:47 +0100, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Release-Acked-by: Oleksii Kurochko ~ Oleksii > --- > CC: Stefano Stabellini > CC: Michal Orzel > CC: Roger Pau Monné > CC: Oleksii Kurochko > CC: Jan Beulich > > Updated run: >   https://cirrus-ci.com/

Re: [PATCH 08/26] virtio_blk: remove virtblk_update_cache_mode

On Tue, Jun 11, 2024 at 07:19:08AM +0200, Christoph Hellwig wrote: > 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/

Re: [PATCH for-4.19] CI: Update FreeBSD to 13.3

On Tue, 11 Jun 2024, Roger Pau Monné wrote: > On Tue, Jun 11, 2024 at 01:47:01PM +0100, Andrew Cooper wrote: > > Signed-off-by: Andrew Cooper > > Acked-by: Roger Pau Monné Acked-by: Stefano Stabellini

[XEN PATCH 1/6] automation/eclair: address violations of MISRA C Rule 20.7

MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". The helper macro bitmap_switch has parameters that cannot be parenthesized in order to comply with the rule, as that would break its functionality. Moreover, the risk of misus

[XEN PATCH 0/6] address several violations of MISRA Rule 20.7

Hi all, this series addresses several violations of Rule 20.7, as well as a small fix to the ECLAIR integration scripts that do not influence the current behaviour, but were mistakenly part of the upstream configuration. Note that by applying this series the rule has a few leftover violations. Mo

[XEN PATCH 2/6] xen/self-tests: address violations of MISRA rule 20.7

MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter

[XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter

Re: [PATCH v12 5/8] xen/riscv: add minimal stuff to mm.h to build full Xen

On 30/05/2024 7:22 pm, Oleksii K. wrote: > On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote: >> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote: >>> Signed-off-by: Oleksii Kurochko >>> Acked-by: Jan Beulich >> This patch looks like it can go in independently?  Or does it depend >> on >> havin

[XEN PATCH 5/6] x86/irq: address violations of MISRA C Rule 20.7

MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter

[XEN PATCH 6/6] automation/eclair_analysis: clean ECLAIR configuration scripts

Remove from the ECLAIR integration scripts an unused option, which was already ignored, and make the help texts consistent with the rest of the scripts. No functional change. Signed-off-by: Nicola Vetrini --- automation/eclair_analysis/ECLAIR/analyze.sh | 3 +-- 1 file changed, 1 insertion(+),

[XEN PATCH 3/6] xen/guest_access: address violations of MISRA rule 20.7

MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter

  1   2   >