[PATCH 10/27] block: add a bdev_nonrot helper

Add a helper to check the nonrot flag based on the block_device instead of having to poke into the block layer internal request_queue. Signed-off-by: Christoph Hellwig --- block/ioctl.c | 2 +- drivers/block/loop.c| 2 +- drivers/md/dm-table.c

[PATCH 12/27] block: add a bdev_fua helper

Add a helper to check the FUA flag based on the block_device instead of having to poke into the block layer internal request_queue. Signed-off-by: Christoph Hellwig --- drivers/block/rnbd/rnbd-srv.c | 3 +-- drivers/target/target_core_iblock.c | 3 +-- fs/iomap/direct-io.c|

[PATCH 16/27] drbd: use bdev_alignment_offset instead of queue_alignment_offset

The bdev version does the right thing for partitions, so use that. Fixes: 9104d31a759f ("drbd: introduce WRITE_SAME support") Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/drbd/drbd_main.c b/d

[PATCH 15/27] block: use bdev_alignment_offset in part_alignment_offset_show

Replace the open coded offset calculation with the proper helper. This is an ABI change in that the -1 for a misaligned partition is properly propagated, which can be considered a bug fix and maches what is done on the whole device. Signed-off-by: Christoph Hellwig --- block/partitions/core.c |

[PATCH 23/27] block: add a bdev_max_discard_sectors helper

Add a helper to query the number of sectors support per each discard bio based on the block device and use this helper to stop various places from poking into the request_queue to see if discard is supported and if so how much. This mirrors what is done e.g. for write zeroes as well. Signed-off-b

[PATCH 14/27] block: add a bdev_max_zone_append_sectors helper

Add a helper to check the max supported sectors for zone append based on the block_device instead of having to poke into the block layer internal request_queue. Signed-off-by: Christoph Hellwig --- drivers/nvme/target/zns.c | 3 +-- fs/zonefs/super.c | 3 +-- include/linux/blkdev.h|

[PATCH 13/27] block: add a bdev_stable_writes helper

Add a helper to check the stable writes flag based on the block_device instead of having to poke into the block layer internal request_queue. Signed-off-by: Christoph Hellwig --- drivers/md/dm-table.c | 4 +--- fs/super.c | 2 +- include/linux/blkdev.h | 6 ++ mm/swapfile.c

[PATCH 26/27] block: uncouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD

Secure erase is a very different operation from discard in that it is a data integrity operation vs hint. Fully split the limits and helper infrastructure to make the separation more clear. Signed-off-by: Christoph Hellwig --- block/blk-core.c| 2 +- block/blk-lib.c

[PATCH 25/27] block: remove QUEUE_FLAG_DISCARD

Just use a non-zero max_discard_sectors as an indicator for discard support, similar to what is done for write zeroes. The only places where needs special attention is the RAID5 driver, which must clear discard support for security reasons by default, even if the default stacking rules would allow

[PATCH 27/27] direct-io: remove random prefetches

Randomly poking into block device internals for manual prefetches isn't exactly a very maintainable thing to do. And none of the performance criticil direct I/O implementations still use this library function anyway, so just drop it. Signed-off-by: Christoph Hellwig --- fs/direct-io.c | 32

[PATCH 17/27] block: use bdev_alignment_offset in disk_alignment_offset_show

This does the same as the open coded variant except for an extra branch, and allows to remove queue_alignment_offset entirely. Signed-off-by: Christoph Hellwig --- block/genhd.c | 2 +- include/linux/blkdev.h | 8 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/bl

[PATCH 20/27] block: use bdev_discard_alignment in part_discard_alignment_show

Use the bdev based alignment helper instead of open coding it. Signed-off-by: Christoph Hellwig --- block/partitions/core.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/block/partitions/core.c b/block/partitions/core.c index 240b3fff521e4..70dec1c78521d 100644 --- a/b

[PATCH 24/27] block: add a bdev_discard_granularity helper

Abstract away implementation details from file systems by providing a block_device based helper to retreive the discard granularity. Signed-off-by: Christoph Hellwig --- block/blk-lib.c | 5 ++--- drivers/block/drbd/drbd_nl.c| 9 + drivers/block/drbd/drbd_re

[PATCH 19/27] block: remove queue_discard_alignment

Just use bdev_alignment_offset in disk_discard_alignment_show instead. That helpers is the same except for an always false branch that doesn't matter in this slow path. Signed-off-by: Christoph Hellwig --- block/genhd.c | 2 +- include/linux/blkdev.h | 8 2 files changed, 1 ins

[PATCH 18/27] block: move bdev_alignment_offset and queue_limit_alignment_offset out of line

No need to inline these fairly larger helpers. Signed-off-by: Christoph Hellwig --- block/blk-settings.c | 23 +++ include/linux/blkdev.h | 21 + 2 files changed, 24 insertions(+), 20 deletions(-) diff --git a/block/blk-settings.c b/block/blk-settings.c

[PATCH 09/27] mm: use bdev_is_zoned in claim_swapfile

Use the bdev based helper instead of poking into the queue. Signed-off-by: Christoph Hellwig --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 63c61f8b26118..4c7537162af5e 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2

[PATCH 22/27] block: refactor discard bio size limiting

Move all the logic to limit the discard bio size into a common helper so that it is better documented. Signed-off-by: Christoph Hellwig --- block/blk-lib.c | 59 - block/blk.h | 14 2 files changed, 29 insertions(+), 44 deletions(-

[PATCH 21/27] block: move {bdev,queue_limit}_discard_alignment out of line

No need to inline these fairly larger helpers. Also fix the return value to be unsigned, just like the field in struct queue_limits. Signed-off-by: Christoph Hellwig --- block/blk-settings.c | 35 +++ include/linux/blkdev.h | 34 +---

[PATCH 11/27] block: add a bdev_write_cache helper

Add a helper to check the write cache flag based on the block_device instead of having to poke into the block layer internal request_queue. Signed-off-by: Christoph Hellwig --- drivers/block/rnbd/rnbd-srv.c | 2 +- drivers/block/xen-blkback/xenbus.c | 2 +- drivers/target/target_core_iblo

[PATCH 05/27] drbd: use bdev based limit helpers in drbd_send_sizes

Use the bdev based limits helpers where they exist. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index 74b1b2424efff..d20d84e

[PATCH 07/27] btrfs: use bdev_max_active_zones instead of open coding it

Signed-off-by: Christoph Hellwig --- fs/btrfs/zoned.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index b7b5fac1c7790..5b85004d85d6c 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -350,7 +350,6 @@ int btrfs_get_dev_zone_info(s

[PATCH 06/27] drbd: cleanup decide_on_discard_support

Sanitize the calling conventions and use a goto label to cleanup the code flow. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_nl.c | 68 +++- 1 file changed, 35 insertions(+), 33 deletions(-) diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/bloc

[PATCH 08/27] ntfs3: use bdev_logical_block_size instead of open coding it

Signed-off-by: Christoph Hellwig --- fs/ntfs3/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c index 278dcf5024102..cd30e81abbce0 100644 --- a/fs/ntfs3/super.c +++ b/fs/ntfs3/super.c @@ -920,7 +920,7 @@ static int ntfs_fill_super(stru

[PATCH 03/27] target: fix discard alignment on partitions

Use the proper bdev_discard_alignment helper that accounts for partition offsets. Fіxes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Signed-off-by: Christoph Hellwig --- drivers/target/target_core_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a

[PATCH 02/27] target: pass a block_device to target_configure_unmap_from_queue

The target code is a consumer of the block layer and should generally work on struct block_device. Signed-off-by: Christoph Hellwig --- drivers/target/target_core_device.c | 5 +++-- drivers/target/target_core_file.c| 7 --- drivers/target/target_core_iblock.c | 2 +- include/target/ta

[PATCH 01/27] target: remove an incorrect unmap zeroes data deduction

For block devices the target code implements UNMAP as calls to blkdev_issue_discard, which does not guarantee zeroing just because Write Zeroes is supported. Note that this does not affect the file backed path which uses fallocate to punch holes. Fixes: 2237498f0b5c ("target/iblock: Convert WRITE

use block_device based APIs in block layer consumers

Hi Jens, this series cleanups up the block layer API so that APIs consumed by file systems are (almost) only struct block_devic based, so that file systems don't have to poke into block layer internals like the request_queue. I also found a bunch of existing bugs related to partition offsets and

[PATCH 04/27] drbd: remove assign_p_sizes_qlim

Fold each branch into its only caller. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 50 -- 1 file changed, 23 insertions(+), 27 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index 9676a1d214bc5.

[xen-4.16-testing test] 169179: tolerable FAIL - PUSHED

flight 169179 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169179/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169119 test-amd64-amd64-xl-qemuu-win7-a

[xen-4.13-testing test] 169180: tolerable FAIL - PUSHED

flight 169180 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169180/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168481 test-amd64-i386-xl-qemuu-win7-am

Re: Increasing domain memory beyond initial maxmem

On 05.04.22 18:24, Marek Marczykowski-Górecki wrote: On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote: Hi Marek, On 31.03.22 14:36, Marek Marczykowski-Górecki wrote: On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote: Maybe some kernel config differences, or other udev

[xen-4.15-testing test] 169178: tolerable FAIL - PUSHED

flight 169178 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169178/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169162 test-amd64-amd64-xl-qemut-win7-a

Re: [PATCH v4 8/9] tools: add example application to initialize dom0less PV drivers

On Fri, 1 Apr 2022, Juergen Gross wrote: > On 01.04.22 12:21, Julien Grall wrote: > > Hi, > > > > I have posted some comments in v3 after you sent this version. Please have a > > look. > > > > On 01/04/2022 01:38, Stefano Stabellini wrote: > > > +static int init_domain(struct xs_handle *xsh, libx

Re: [PATCH] arm/xen: Fix refcount leak in xen_dt_guest_init

Hi, On Fri, Mar 11, 2022 at 06:01:11PM -0800, Stefano Stabellini wrote: > On Wed, 9 Mar 2022, Miaoqian Lin wrote: > > The of_find_compatible_node() function returns a node pointer with > > refcount incremented, We should use of_node_put() on it when done > > Add the missing of_node_put() to releas

Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

On 4/1/22 9:21 AM, Chuck Zmudzinski wrote: On 3/30/22 2:45 PM, Jason Andryuk wrote: On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote: On 14.03.2022 04:41, Chuck Zmudzinski wrote: When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD opregion to the guest but libxl does no

Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers

On Tue, 5 Apr 2022, Stefano Stabellini wrote: > On Fri, 1 Apr 2022, Julien Grall wrote: > > On 01/04/2022 01:35, Stefano Stabellini wrote: > > > > > > > + > > > > > > > +/* Alloc magic pages */ > > > > > > > +if (alloc_magic_pages(info, &dom) != 0) { > > > > > > > +printf("Error on

Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers

On Fri, 1 Apr 2022, Juergen Gross wrote: > On 01.04.22 12:02, Julien Grall wrote: > > Hi Stefano, > > > > On 01/04/2022 01:35, Stefano Stabellini wrote: > > > > > > > + > > > > > > > +    /* Alloc magic pages */ > > > > > > > +    if (alloc_magic_pages(info, &dom) != 0) { > > > > > > > +    pr

Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers

On Fri, 1 Apr 2022, Julien Grall wrote: > On 01/04/2022 01:35, Stefano Stabellini wrote: > > > > > > + > > > > > > +/* Alloc magic pages */ > > > > > > +if (alloc_magic_pages(info, &dom) != 0) { > > > > > > +printf("Error on alloc magic pages\n"); > > > > > > +return 1; > >

Re: [PATCH v3 13/19] xen/arm: Move fixmap definitions in a separate header

On Tue, 5 Apr 2022, Julien Grall wrote: > On 05/04/2022 22:12, Stefano Stabellini wrote: > > > +/* Map a page in a fixmap entry */ > > > +extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes); > > > +/* Remove a mapping from a fixmap entry */ > > > +extern void clear_fixmap(unsigned

Re: [PATCH v3 17/19] xen/arm64: mm: Add memory to the boot allocator first

On Tue, 5 Apr 2022, Julien Grall wrote: > On 05/04/2022 22:50, Stefano Stabellini wrote: > > > +static void __init setup_mm(void) > > > +{ > > > +const struct meminfo *banks = &bootinfo.mem; > > > +paddr_t ram_start = ~0; > > > +paddr_t ram_end = 0; > > > +paddr_t ram_size = 0; > >

Re: [PATCH v3 19/19] xen/arm: mm: Re-implement setup_frame_table_mappings() with map_pages_to_xen()

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > Now that map_pages_to_xen() has been extended to support 2MB mappings, > we can replace the create_mappings() call by map_pages_to_xen() call. > > This has the advantage to remove the differences between 32-bit and > 64-bit code.

Re: [PATCH v3 18/19] xen/arm: mm: Rework setup_xenheap_mappings()

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > The current implementation of setup_xenheap_mappings() is using 1GB > mappings. This can lead to unexpected result because the mapping > may alias a non-cachable region (such as device or reserved regions). > For more details see B

[xen-unstable test] 169172: tolerable FAIL

flight 169172 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169172/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-amd64 19 guest-localmigrate/x10 fail pass in 169163 test-amd64-amd64-xl-qemut-debian

Re: [PATCH v3 17/19] xen/arm64: mm: Add memory to the boot allocator first

Hi Stefano, On 05/04/2022 22:50, Stefano Stabellini wrote: +static void __init setup_mm(void) +{ +const struct meminfo *banks = &bootinfo.mem; +paddr_t ram_start = ~0; +paddr_t ram_end = 0; +paddr_t ram_size = 0; +unsigned int i; + +init_pdx(); + +/* + * We need s

Re: [PATCH v3 17/19] xen/arm64: mm: Add memory to the boot allocator first

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > Currently, memory is added to the boot allocator after the xenheap > mappings are done. This will break if the first mapping is more than > 512GB of RAM. > > In addition to that, a follow-up patch will rework setup_xenheap_mapping

Re: [PATCH v3 13/19] xen/arm: Move fixmap definitions in a separate header

Hi Stefano, On 05/04/2022 22:12, Stefano Stabellini wrote: +/* Map a page in a fixmap entry */ +extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes); +/* Remove a mapping from a fixmap entry */ +extern void clear_fixmap(unsigned map); + +#endif /* __ASSEMBLY__ */ + +#endif /* __A

Re: [PATCH v3 16/19] xen/arm: mm: Use the PMAP helpers in xen_{,un}map_table()

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > During early boot, it is not possible to use xen_{,un}map_table() > if the page tables are not residing the Xen binary. > > This is a blocker to switch some of the helpers to use xen_pt_update() > as we may need to allocate extra

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

flight 169174 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/169174/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 169145 test-amd64-amd64-xl-qemut-win7-amd

Re: [PATCH v3 15/19] xen/arm: mm: Clean-up the includes and order them

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > The numbers of includes in mm.c has been growing quite a lot. However > some of them (e.g. xen/device_tree.h, xen/softirq.h) doesn't look > to be directly used by the file or other will be included by > larger headers (e.g asm/flus

Re: [PATCH v3 14/19] xen/arm: add Persistent Map (PMAP) infrastructure

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Wei Liu > > The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We > pre-populate all the relevant page tables before the system is fully > set up. > > We will need it on Arm in order to rework the arm64 version of > xenheap_setup_mappi

Re: [PATCH v3 13/19] xen/arm: Move fixmap definitions in a separate header

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > To use properly the fixmap definitions, their user would need > also new to include . This is not very great when > the user itself is not meant to directly use ACPI definitions. > > Including in is not option because > the latt

Re: [PATCH v3 12/19] xen/arm: mm: Allow page-table allocation from the boot allocator

On Mon, 21 Feb 2022, Julien Grall wrote: > From: Julien Grall > > At the moment, page-table can only be allocated from domheap. This means > it is not possible to create mapping in the page-tables via > map_pages_to_xen() if page-table needs to be allocated. > > In order to avoid open-coding pag

Re: [PATCH v3 07/19] xen/arm: mm: Don't open-code Xen PT update in remove_early_mappings()

On Sat, 2 Apr 2022, Julien Grall wrote: > On 02/04/2022 01:04, Stefano Stabellini wrote: > > On Mon, 21 Feb 2022, Julien Grall wrote: > > > From: Julien Grall > > > > > > Now that xen_pt_update_entry() is able to deal with different mapping > > > size, we can replace the open-coding of the page-t

Re: [PATCH v3 06/19] xen/arm: mm: Avoid flushing the TLBs when mapping are inserted

On Sat, 2 Apr 2022, Julien Grall wrote: > Hi Stefano, > > On 02/04/2022 01:00, Stefano Stabellini wrote: > > On Mon, 21 Feb 2022, Julien Grall wrote: > > > From: Julien Grall > > > > > > Currently, the function xen_pt_update() will flush the TLBs even when > > > the mappings are inserted. This i

Re: [PATCH v3 05/19] xen/arm: mm: Add support for the contiguous bit

On Sat, 2 Apr 2022, Julien Grall wrote: > On 02/04/2022 00:53, Stefano Stabellini wrote: > > On Mon, 21 Feb 2022, Julien Grall wrote: > > > @@ -1333,21 +1386,34 @@ static int xen_pt_update(unsigned long virt, > > > while ( left ) > > > { > > > unsigned int order, level; > > >

Re: [PATCH v3 04/19] xen/arm: mm: Allow other mapping size in xen_pt_update_entry()

On Sat, 2 Apr 2022, Julien Grall wrote: > On 02/04/2022 00:35, Stefano Stabellini wrote: > > > +/* Return the level where mapping should be done */ > > > +static int xen_pt_mapping_level(unsigned long vfn, mfn_t mfn, unsigned > > > long nr, > > > +unsigned int flags)

Re: cleanup swiotlb initialization v8

On 4/4/22 1:05 AM, Christoph Hellwig wrote: Hi all, this series tries to clean up the swiotlb initialization, including that of swiotlb-xen. To get there is also removes the x86 iommu table infrastructure that massively obsfucates the initialization path. Git tree: git://git.infradead.

Design meeting for AMD SEV-SNP project

Hello everyone, As announced during earlier community call, I'm posting here to announce our intention to bootstrap Xen support of AMD SEV-SNP technology. In very short, this hardware extension on AMD CPUs will allow to run encrypted memory in guests, except for explicitly permitted areas. The

Re: [PATCH v2] Grab the EFI System Resource Table and check it

> On 5 Apr 2022, at 20:21, Stefano Stabellini wrote: > > On Mon, 4 Apr 2022, Luca Fancellu wrote: >>> On 2 Apr 2022, at 00:14, Demi Marie Obenour >>> wrote: >>> >>> The EFI System Resource Table (ESRT) is necessary for fwupd to identify >>> firmware updates to install. According to the UEFI

Re: [PATCH v2] Grab the EFI System Resource Table and check it

On Mon, 4 Apr 2022, Luca Fancellu wrote: > > On 2 Apr 2022, at 00:14, Demi Marie Obenour > > wrote: > > > > The EFI System Resource Table (ESRT) is necessary for fwupd to identify > > firmware updates to install. According to the UEFI specification §23.4, > > the table shall be stored in memory

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On 4/5/22 13:17, Jason Andryuk wrote: > On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith > wrote: >> >> On 3/31/22 09:16, Jason Andryuk wrote: >>> On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith >>> wrote: There are now instances where internal hypervisor logic needs to make resour

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

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

[ovmf test] 169177: regressions - FAIL

flight 169177 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169177/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On Mon, Apr 4, 2022 at 11:34 AM Daniel P. Smith wrote: > > On 3/31/22 09:16, Jason Andryuk wrote: > > On Wed, Mar 30, 2022 at 3:05 PM Daniel P. Smith > > wrote: > >> > >> There are now instances where internal hypervisor logic needs to make > >> resource > >> allocation calls that are protected

[libvirt test] 169171: regressions - FAIL

flight 169171 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169171/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt

Re: Increasing domain memory beyond initial maxmem

On Tue, Apr 05, 2022 at 01:03:57PM +0200, Juergen Gross wrote: > Hi Marek, > > On 31.03.22 14:36, Marek Marczykowski-Górecki wrote: > > On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote: > > > Maybe some kernel config differences, or other udev rules (memory onlining > > > is done via

Re: [PATCH v4 3/8] x86/EFI: retrieve EDID

On Tue, Apr 05, 2022 at 04:36:53PM +0200, Jan Beulich wrote: > On 05.04.2022 12:27, Roger Pau Monné wrote: > > On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote: > >> --- a/xen/arch/x86/efi/efi-boot.h > >> +++ b/xen/arch/x86/efi/efi-boot.h > >> @@ -568,6 +568,49 @@ static void __init efi_

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On Tue, Apr 05, 2022 at 08:06:31AM -0400, Daniel P. Smith wrote: > On 4/5/22 03:42, Roger Pau Monné wrote: > > On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote: > >> On 4/4/22 11:12, Roger Pau Monné wrote: > >>> On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote: >

Re: [PATCH] x86/irq: Skip unmap_domain_pirq XSM during destruction

On Tue, Apr 5, 2022 at 4:18 AM Jan Beulich wrote: > > On 30.03.2022 20:17, Jason Andryuk wrote: > > xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from > > complete_domain_destroy as an RCU callback. The source context was an > > unexpected, random domain. Since this is a xe

[xen-4.14-testing test] 169170: regressions - FAIL

flight 169170 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/169170/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 18 guest-localmigrate fail REGR. vs. 168506 build-arm64-xs

Re: [PATCH v4 3/8] x86/EFI: retrieve EDID

On 05.04.2022 12:27, Roger Pau Monné wrote: > On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote: >> --- a/xen/arch/x86/efi/efi-boot.h >> +++ b/xen/arch/x86/efi/efi-boot.h >> @@ -568,6 +568,49 @@ static void __init efi_arch_video_init(E >> #endif >> } >> >> +#ifdef CONFIG_VIDEO >> +sta

Re: [PATCH 1/2] hw/xen/xen_pt: Confine igd-passthrough-isa-bridge to XEN

On Sat, Mar 26, 2022 at 05:58:23PM +0100, Bernhard Beschow wrote: > igd-passthrough-isa-bridge is only requested in xen_pt but was > implemented in pc_piix.c. This caused xen_pt to dependend on i386/pc > which is hereby resolved. > > Signed-off-by: Bernhard Beschow Acked-by: Anthony PERARD Tha

Re: [PATCH 2/2] hw/xen/xen_pt: Resolve igd_passthrough_isa_bridge_create() indirection

On Sat, Mar 26, 2022 at 05:58:24PM +0100, Bernhard Beschow wrote: > Now that igd_passthrough_isa_bridge_create() is implemented within the > xen context it may use Xen* data types directly and become > xen_igd_passthrough_isa_bridge_create(). This resolves an indirection. > > Signed-off-by: Bernha

[PATCH] osstest: stop anacron service

Just disabling cron in rc.d is not enough. There's also anacron which will get invoked during startup, and since apt-compat has a delay of up to 30min it can be picked up by the leak detector if the test finishes fast enough: LEAKED [process 14563 sleep] process: root 14563 14556 0 07:49 ?

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

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

Re: preparations for 4.14.5 ?

On Mon, Apr 04, 2022 at 03:42:09PM +0200, Jan Beulich wrote: > On 01.04.2022 15:46, Marek Marczykowski-Górecki wrote: > > On Wed, Mar 30, 2022 at 12:16:00PM +0200, Jan Beulich wrote: > > I'm not sure if "just" bugfix qualify for 4.14 at this point, but if so, > > I'd propose: > > 0a20a53df158 tools

Re: [PATCH] x86/irq: Skip unmap_domain_pirq XSM during destruction

On 4/5/22 04:18, Jan Beulich wrote: > On 30.03.2022 20:17, Jason Andryuk wrote: >> xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from >> complete_domain_destroy as an RCU callback. The source context was an >> unexpected, random domain. Since this is a xen-internal operation

Re: [PATCH 2/2] arch: ensure idle domain is not left privileged

On 4/5/22 04:26, Jan Beulich wrote: > On 31.03.2022 01:05, Daniel P. Smith wrote: >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -589,6 +589,9 @@ static void noinline init_done(void) >> void *va; >> unsigned long start, end; >> >> +/* Ensure idle domain was not le

[ovmf test] 169173: regressions - FAIL

flight 169173 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169173/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm

Re: [PATCH 1/2] xsm: add ability to elevate a domain to privileged

On 4/5/22 03:42, Roger Pau Monné wrote: > On Mon, Apr 04, 2022 at 12:08:25PM -0400, Daniel P. Smith wrote: >> On 4/4/22 11:12, Roger Pau Monné wrote: >>> On Mon, Apr 04, 2022 at 10:21:18AM -0400, Daniel P. Smith wrote: On 3/31/22 08:36, Roger Pau Monné wrote: > On Wed, Mar 30, 2022 at 07:0

Xen Security Advisory 399 v2 (CVE-2022-26357) - race in VT-d domain ID cleanup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-26357 / XSA-399 version 2 race in VT-d domain ID cleanup UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION =

Xen Security Advisory 397 v2 (CVE-2022-26356) - Racy interactions between dirty vram tracking and paging log dirty hypercalls

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-26356 / XSA-397 version 2 Racy interactions between dirty vram tracking and paging log dirty hypercalls UPDATES IN VERSION 2 Public release. ISSUE DES

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

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

Re: [PATCH v4 2/8] x86/boot: obtain video info from boot loader

On Tue, Apr 05, 2022 at 12:57:51PM +0200, Jan Beulich wrote: > On 05.04.2022 11:35, Roger Pau Monné wrote: > > On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote: > >> --- a/xen/arch/x86/boot/head.S > >> +++ b/xen/arch/x86/boot/head.S > >> @@ -562,12 +562,18 @@ trampoline_setup: > >>

Re: [PATCH 1/2] hw/xen/xen_pt: Confine igd-passthrough-isa-bridge to XEN

Am 26. März 2022 16:58:23 UTC schrieb Bernhard Beschow : >igd-passthrough-isa-bridge is only requested in xen_pt but was >implemented in pc_piix.c. This caused xen_pt to dependend on i386/pc >which is hereby resolved. > >Signed-off-by: Bernhard Beschow >--- > hw/i386/pc_piix.c| 118 ---

Re: [PATCH v4 8/8] x86/boot: fold two MOVs into an ADD

On Thu, Mar 31, 2022 at 11:51:02AM +0200, Jan Beulich wrote: > There's no point going through %ax; the addition can be done directly in > %di. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH v4 7/8] x86/boot: LEA -> MOV in video handling code

On Thu, Mar 31, 2022 at 11:50:20AM +0200, Jan Beulich wrote: > Replace most LEA instances with (one byte shorter) MOV. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH v4 6/8] x86/boot: fold/replace moves in video handling code

On Thu, Mar 31, 2022 at 11:50:00AM +0200, Jan Beulich wrote: > Replace (mainly) MOV forms with shorter insns (or sequences thereof). > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH 1/2] tools/firmware: fix setting of fcf-protection=none

On 05/04/2022 12:04, Jan Beulich wrote: > On 05.04.2022 12:58, Andrew Cooper wrote: >> On 05/04/2022 11:18, Jan Beulich wrote: >>> On 01.04.2022 17:05, Andrew Cooper wrote: On 01/04/2022 15:48, Andrew Cooper wrote: > On 01/04/2022 15:37, Roger Pau Monne wrote: >> Setting the fcf-protec

Re: [PATCH 1/2] tools/firmware: fix setting of fcf-protection=none

On 05.04.2022 12:58, Andrew Cooper wrote: > On 05/04/2022 11:18, Jan Beulich wrote: >> On 01.04.2022 17:05, Andrew Cooper wrote: >>> On 01/04/2022 15:48, Andrew Cooper wrote: On 01/04/2022 15:37, Roger Pau Monne wrote: > Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in th

Re: Increasing domain memory beyond initial maxmem

Hi Marek, On 31.03.22 14:36, Marek Marczykowski-Górecki wrote: On Thu, Mar 31, 2022 at 02:22:03PM +0200, Juergen Gross wrote: Maybe some kernel config differences, or other udev rules (memory onlining is done via udev in my guest)? I'm seeing: # zgrep MEMORY_HOTPLUG /proc/config.gz CONFIG_ARC

Re: [PATCH 1/2] tools/firmware: fix setting of fcf-protection=none

On 05/04/2022 11:18, Jan Beulich wrote: > On 01.04.2022 17:05, Andrew Cooper wrote: >> On 01/04/2022 15:48, Andrew Cooper wrote: >>> On 01/04/2022 15:37, Roger Pau Monne wrote: Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in the Makefile doesn't get it propagated to the

Re: [PATCH v4 2/8] x86/boot: obtain video info from boot loader

On 05.04.2022 11:35, Roger Pau Monné wrote: > On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote: >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -562,12 +562,18 @@ trampoline_setup: >> mov %esi, sym_esi(xen_phys_start) >> mov %esi, sym_e

Re: [PATCH v4 5/8] x86/boot: fold branches in video handling code

On Thu, Mar 31, 2022 at 11:49:24AM +0200, Jan Beulich wrote: > Using Jcc to branch around a JMP is necessary only in pre-386 code, > where Jcc is limited to disp8. Use the opposite Jcc directly in two > places. Since it's adjacent, also convert an ORB to TESTB. > > Signed-off-by: Jan Beulich Rev

Re: [PATCH v4 4/8] x86/boot: simplify mode_table

On Thu, Mar 31, 2022 at 11:48:51AM +0200, Jan Beulich wrote: > There's no point in writing 80x25 text mode information via multiple > insns all storing immediate values. The data can simply be included > first thing in the vga_modes table, allowing the already present > REP MOVSB to take care of ev

[seabios test] 169167: tolerable FAIL - PUSHED

flight 169167 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/169167/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168315 test-amd64-amd64-qemuu-nested-amd 20 debi

Re: [PATCH v4 3/8] x86/EFI: retrieve EDID

On Thu, Mar 31, 2022 at 11:45:36AM +0200, Jan Beulich wrote: > When booting directly from EFI, obtaining this information from EFI is > the only possible way. And even when booting with a boot loader > interposed, it's more clean not to use legacy BIOS calls for this > purpose. (The downside being

Re: [PATCH 1/2] tools/firmware: fix setting of fcf-protection=none

On 01.04.2022 17:05, Andrew Cooper wrote: > On 01/04/2022 15:48, Andrew Cooper wrote: >> On 01/04/2022 15:37, Roger Pau Monne wrote: >>> Setting the fcf-protection=none option in EMBEDDED_EXTRA_CFLAGS in the >>> Makefile doesn't get it propagated to the subdirectories, so instead >>> set the flag i

Re: [PATCH v4 4/9] xen: export evtchn_alloc_unbound

On 01.04.2022 02:38, Stefano Stabellini wrote: > From: Stefano Stabellini > > It will be used during dom0less domains construction. > > Signed-off-by: Stefano Stabellini I think this better wouldn't be a patch of its own. Functions should be non-static only when they have a user outside of the

Re: [PATCH v4 2/8] x86/boot: obtain video info from boot loader

On Thu, Mar 31, 2022 at 11:45:02AM +0200, Jan Beulich wrote: > With MB2 the boot loader may provide this information, allowing us to > obtain it without needing to enter real mode (assuming we don't need to > set a new mode from "vga=", but can instead inherit the one the > bootloader may have esta

  1   2   >