[ovmf test] 169323: regressions - FAIL
flight 169323 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169323/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 42 days 337 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days 10 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
Re: [PATCH 10/15] swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction
On Wed, Apr 06, 2022 at 08:25:32PM -0400, Konrad Rzeszutek Wilk wrote: > > diff --git a/arch/powerpc/platforms/pseries/svm.c > > b/arch/powerpc/platforms/pseries/svm.c > > index c5228f4969eb2..3b4045d508ec8 100644 > > --- a/arch/powerpc/platforms/pseries/svm.c > > +++ b/arch/powerpc/platforms/pseries/svm.c > > @@ -28,7 +28,7 @@ static int __init init_svm(void) > > * need to use the SWIOTLB buffer for DMA even if dma_capable() says > > * otherwise. > > */ > > - swiotlb_force = SWIOTLB_FORCE; > > + ppc_swiotlb_flags |= SWIOTLB_ANY | SWIOTLB_FORCE; > > This is the only place you set the ppc_swiotlb_flags.. so I wonder why > the '|=' instead of just '=' ? Preparing for setting others and not clobbering the value.
[PATCH v7 16/20] mips: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/mips/kernel/reset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 6288780b779e..e7ce07b3e79b 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -114,8 +114,7 @@ void machine_halt(void)
void machine_power_off(void)
{
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
#ifdef CONFIG_SMP
preempt_disable();
--
2.35.1
[PATCH v7 15/20] ia64: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/ia64/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index d7a256bd9d6b..89025e3b3f61 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -599,8 +600,7 @@ machine_halt (void)
void
machine_power_off (void)
{
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
machine_halt();
}
--
2.35.1
[PATCH v7 12/20] m68k: Switch to new sys-off handler API
Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new power-off API.
Normally arch code should adopt only the do_kernel_power_off() at first,
but m68k is a special case because it uses pm_power_off() "inside out",
i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing],
while it's machine_power_off() that should invoke the pm_power_off(), and
thus, we can't convert platforms to the new API separately. There are only
two platforms changed here, so it's not a big deal.
Acked-by: Geert Uytterhoeven
Signed-off-by: Dmitry Osipenko
---
arch/m68k/emu/natfeat.c | 3 ++-
arch/m68k/include/asm/machdep.h | 1 -
arch/m68k/kernel/process.c | 5 ++---
arch/m68k/kernel/setup_mm.c | 1 -
arch/m68k/kernel/setup_no.c | 1 -
arch/m68k/mac/config.c | 4 +++-
6 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/m68k/emu/natfeat.c b/arch/m68k/emu/natfeat.c
index 71b78ecee75c..b19dc00026d9 100644
--- a/arch/m68k/emu/natfeat.c
+++ b/arch/m68k/emu/natfeat.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -90,5 +91,5 @@ void __init nf_init(void)
pr_info("NatFeats found (%s, %lu.%lu)\n", buf, version >> 16,
version & 0x);
- mach_power_off = nf_poweroff;
+ register_platform_power_off(nf_poweroff);
}
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 8fd80ef1b77e..8d8c3ee2069f 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -24,7 +24,6 @@ extern int (*mach_get_rtc_pll)(struct rtc_pll_info *);
extern int (*mach_set_rtc_pll)(struct rtc_pll_info *);
extern void (*mach_reset)( void );
extern void (*mach_halt)( void );
-extern void (*mach_power_off)( void );
extern unsigned long (*mach_hd_init) (unsigned long, unsigned long);
extern void (*mach_hd_setup)(char *, int *);
extern void (*mach_heartbeat) (int);
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index a6030dbaa089..e160a7c57bd3 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -67,12 +67,11 @@ void machine_halt(void)
void machine_power_off(void)
{
- if (mach_power_off)
- mach_power_off();
+ do_kernel_power_off();
for (;;);
}
-void (*pm_power_off)(void) = machine_power_off;
+void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 8f94feed969c..47d55541612f 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -98,7 +98,6 @@ EXPORT_SYMBOL(mach_get_rtc_pll);
EXPORT_SYMBOL(mach_set_rtc_pll);
void (*mach_reset)( void );
void (*mach_halt)( void );
-void (*mach_power_off)( void );
#ifdef CONFIG_HEARTBEAT
void (*mach_heartbeat) (int);
EXPORT_SYMBOL(mach_heartbeat);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 5e4104f07a44..00bf82258233 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -55,7 +55,6 @@ int (*mach_hwclk) (int, struct rtc_time*);
/* machine dependent reboot functions */
void (*mach_reset)(void);
void (*mach_halt)(void);
-void (*mach_power_off)(void);
#ifdef CONFIG_M68000
#if defined(CONFIG_M68328)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 65d124ec80bb..382f656c29ea 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -140,7 +141,6 @@ void __init config_mac(void)
mach_hwclk = mac_hwclk;
mach_reset = mac_reset;
mach_halt = mac_poweroff;
- mach_power_off = mac_poweroff;
#if IS_ENABLED(CONFIG_INPUT_M68K_BEEP)
mach_beep = mac_mksound;
#endif
@@ -160,6 +160,8 @@ void __init config_mac(void)
if (macintosh_config->ident == MAC_MODEL_IICI)
mach_l2_flush = via_l2_flush;
+
+ register_platform_power_off(mac_poweroff);
}
--
2.35.1
[PATCH v7 09/20] parisc: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new power-off API. Acked-by: Helge Deller # parisc Signed-off-by: Dmitry Osipenko --- arch/parisc/kernel/process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c index 28b6a2a5574c..d145184696ea 100644 --- a/arch/parisc/kernel/process.c +++ b/arch/parisc/kernel/process.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -116,8 +117,7 @@ void machine_power_off(void) pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN); /* ipmi_poweroff may have been installed. */ - if (pm_power_off) - pm_power_off(); + do_kernel_power_off(); /* It seems we have no way to power the system off via * software. The user has to press the button himself. */ -- 2.35.1
[PATCH v7 10/20] xen/x86: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Juergen Gross
Signed-off-by: Dmitry Osipenko
---
arch/x86/xen/enlighten_pv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 5038edb79ad5..af1f6e886225 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1071,8 +1072,7 @@ static void xen_machine_halt(void)
static void xen_machine_power_off(void)
{
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
xen_reboot(SHUTDOWN_poweroff);
}
--
2.35.1
Re: [f2fs-dev] [PATCH 26/27] block: uncouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
On 04/06, Christoph Hellwig wrote:
> 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 | 64 -
> block/blk-mq-debugfs.c | 1 -
> block/blk-settings.c| 16 +++-
> block/fops.c| 2 +-
> block/ioctl.c | 43 +++
> drivers/block/drbd/drbd_receiver.c | 5 ++-
> drivers/block/rnbd/rnbd-clt.c | 4 +-
> drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
> drivers/block/xen-blkback/blkback.c | 15 +++
> drivers/block/xen-blkback/xenbus.c | 5 +--
> drivers/block/xen-blkfront.c| 5 ++-
> drivers/md/bcache/alloc.c | 2 +-
> drivers/md/dm-table.c | 8 ++--
> drivers/md/dm-thin.c| 4 +-
> drivers/md/md.c | 2 +-
> drivers/md/raid5-cache.c| 6 +--
> drivers/mmc/core/queue.c| 2 +-
> drivers/nvme/target/io-cmd-bdev.c | 2 +-
> drivers/target/target_core_file.c | 2 +-
> drivers/target/target_core_iblock.c | 2 +-
> fs/btrfs/extent-tree.c | 4 +-
> fs/ext4/mballoc.c | 2 +-
> fs/f2fs/file.c | 16
> fs/f2fs/segment.c | 2 +-
For f2fs,
Acked-by: Jaegeuk Kim
Thank you,
> fs/jbd2/journal.c | 2 +-
> fs/nilfs2/sufile.c | 4 +-
> fs/nilfs2/the_nilfs.c | 4 +-
> fs/ntfs3/super.c| 2 +-
> fs/xfs/xfs_discard.c| 2 +-
> fs/xfs/xfs_log_cil.c| 2 +-
> include/linux/blkdev.h | 27 +++-
> mm/swapfile.c | 6 +--
> 33 files changed, 168 insertions(+), 99 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index b5c3a8049134c..ee18b6a699bdf 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -824,7 +824,7 @@ void submit_bio_noacct(struct bio *bio)
> goto not_supported;
> break;
> case REQ_OP_SECURE_ERASE:
> - if (!blk_queue_secure_erase(q))
> + if (!bdev_max_secure_erase_sectors(bdev))
> goto not_supported;
> break;
> case REQ_OP_ZONE_APPEND:
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 43aa4d7fe859f..09b7e1200c0f4 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -36,26 +36,15 @@ static sector_t bio_discard_limit(struct block_device
> *bdev, sector_t sector)
> }
>
> int __blkdev_issue_discard(struct block_device *bdev, sector_t sector,
> - sector_t nr_sects, gfp_t gfp_mask, int flags,
> - struct bio **biop)
> + sector_t nr_sects, gfp_t gfp_mask, struct bio **biop)
> {
> - struct request_queue *q = bdev_get_queue(bdev);
> struct bio *bio = *biop;
> - unsigned int op;
> sector_t bs_mask;
>
> if (bdev_read_only(bdev))
> return -EPERM;
> -
> - if (flags & BLKDEV_DISCARD_SECURE) {
> - if (!blk_queue_secure_erase(q))
> - return -EOPNOTSUPP;
> - op = REQ_OP_SECURE_ERASE;
> - } else {
> - if (!bdev_max_discard_sectors(bdev))
> - return -EOPNOTSUPP;
> - op = REQ_OP_DISCARD;
> - }
> + if (!bdev_max_discard_sectors(bdev))
> + return -EOPNOTSUPP;
>
> /* In case the discard granularity isn't set by buggy device driver */
> if (WARN_ON_ONCE(!bdev_discard_granularity(bdev))) {
> @@ -77,7 +66,7 @@ int __blkdev_issue_discard(struct block_device *bdev,
> sector_t sector,
> sector_t req_sects =
> min(nr_sects, bio_discard_limit(bdev, sector));
>
> - bio = blk_next_bio(bio, bdev, 0, op, gfp_mask);
> + bio = blk_next_bio(bio, bdev, 0, REQ_OP_DISCARD, gfp_mask);
> bio->bi_iter.bi_sector = sector;
> bio->bi_iter.bi_size = req_sects << 9;
> sector += req_sects;
> @@ -103,21 +92,19 @@ EXPORT_SYMBOL(__blkdev_issue_discard);
> * @sector: start sector
> * @nr_sects:number of sectors to discard
> * @gfp_mask:memory allocation flags (for bio_alloc)
> - * @flags: BLKDEV_DISCARD_* flags to control behaviour
> *
> * Description:
> *Issue a discard request for the sectors in question.
> */
> int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
> - sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
> + sector_t nr_sects, gfp_t gfp_mask)
> {
> struct bio *bio = NULL;
> struct blk_plug plug;
> int ret;
>
> blk_start_plug(&plug);
> - ret = __blkdev_issue_dis
[PATCH v7 06/20] csky: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Guo Ren
Signed-off-by: Dmitry Osipenko
---
arch/csky/kernel/power.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
index 923ee4e381b8..86ee202906f8 100644
--- a/arch/csky/kernel/power.c
+++ b/arch/csky/kernel/power.c
@@ -9,16 +9,14 @@ EXPORT_SYMBOL(pm_power_off);
void machine_power_off(void)
{
local_irq_disable();
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
asm volatile ("bkpt");
}
void machine_halt(void)
{
local_irq_disable();
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
asm volatile ("bkpt");
}
--
2.35.1
[PATCH v7 03/20] reboot: Print error message if restart handler has duplicated priority
Add sanity check which ensures that there are no two restart handlers
registered using the same priority. This requirement will become mandatory
once all drivers will be converted to the new API and such errors will be
fixed.
Signed-off-by: Dmitry Osipenko
---
kernel/reboot.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index ed4e6dfb7d44..acdae4e95061 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -182,6 +182,21 @@ static ATOMIC_NOTIFIER_HEAD(restart_handler_list);
*/
int register_restart_handler(struct notifier_block *nb)
{
+ int ret;
+
+ ret = atomic_notifier_chain_register_unique_prio(&restart_handler_list,
nb);
+ if (ret != -EBUSY)
+ return ret;
+
+ /*
+* Handler must have unique priority. Otherwise call order is
+* determined by registration order, which is unreliable.
+*
+* This requirement will become mandatory once all drivers
+* will be converted to use new sys-off API.
+*/
+ pr_err("failed to register restart handler using unique priority\n");
+
return atomic_notifier_chain_register(&restart_handler_list, nb);
}
EXPORT_SYMBOL(register_restart_handler);
--
2.35.1
[PATCH v7 19/20] regulator: pfuze100: Use devm_register_sys_off_handler()
Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.
Acked-by: Mark Brown
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/pfuze100-regulator.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index d60d7d1b7fa2..2eca8d43a097 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,7 @@ struct pfuze_chip {
struct pfuze_regulator regulator_descs[PFUZE100_MAX_REGULATOR];
struct regulator_dev *regulators[PFUZE100_MAX_REGULATOR];
struct pfuze_regulator *pfuze_regulators;
+ struct sys_off_handler sys_off;
};
static const int pfuze100_swbst[] = {
@@ -569,10 +571,10 @@ static inline struct device_node *match_of_node(int index)
return pfuze_matches[index].of_node;
}
-static struct pfuze_chip *syspm_pfuze_chip;
-
-static void pfuze_power_off_prepare(void)
+static void pfuze_power_off_prepare(struct power_off_prep_data *data)
{
+ struct pfuze_chip *syspm_pfuze_chip = data->cb_data;
+
dev_info(syspm_pfuze_chip->dev, "Configure standby mode for power off");
/* Switch from default mode: APS/APS to APS/Off */
@@ -611,24 +613,23 @@ static void pfuze_power_off_prepare(void)
static int pfuze_power_off_prepare_init(struct pfuze_chip *pfuze_chip)
{
+ int err;
+
if (pfuze_chip->chip_id != PFUZE100) {
dev_warn(pfuze_chip->dev, "Requested pm_power_off_prepare
handler for not supported chip\n");
return -ENODEV;
}
- if (pm_power_off_prepare) {
- dev_warn(pfuze_chip->dev, "pm_power_off_prepare is already
registered.\n");
- return -EBUSY;
- }
+ pfuze_chip->sys_off.power_off_prepare_cb = pfuze_power_off_prepare;
+ pfuze_chip->sys_off.cb_data = pfuze_chip;
- if (syspm_pfuze_chip) {
- dev_warn(pfuze_chip->dev, "syspm_pfuze_chip is already set.\n");
- return -EBUSY;
+ err = devm_register_sys_off_handler(pfuze_chip->dev,
&pfuze_chip->sys_off);
+ if (err) {
+ dev_err(pfuze_chip->dev,
+ "failed to register sys-off handler: %d\n", err);
+ return err;
}
- syspm_pfuze_chip = pfuze_chip;
- pm_power_off_prepare = pfuze_power_off_prepare;
-
return 0;
}
@@ -837,23 +838,12 @@ static int pfuze100_regulator_probe(struct i2c_client
*client,
return 0;
}
-static int pfuze100_regulator_remove(struct i2c_client *client)
-{
- if (syspm_pfuze_chip) {
- syspm_pfuze_chip = NULL;
- pm_power_off_prepare = NULL;
- }
-
- return 0;
-}
-
static struct i2c_driver pfuze_driver = {
.driver = {
.name = "pfuze100-regulator",
.of_match_table = pfuze_dt_ids,
},
.probe = pfuze100_regulator_probe,
- .remove = pfuze100_regulator_remove,
};
module_i2c_driver(pfuze_driver);
--
2.35.1
[PATCH v7 20/20] reboot: Remove pm_power_off_prepare()
All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete callback.
Signed-off-by: Dmitry Osipenko
---
include/linux/pm.h | 1 -
kernel/reboot.c| 11 ---
2 files changed, 12 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index ffe941958501..6cdf279c7f2f 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -21,7 +21,6 @@
* Callbacks for platform drivers to implement.
*/
extern void (*pm_power_off)(void);
-extern void (*pm_power_off_prepare)(void);
struct device; /* we have a circular dep with device.h */
#ifdef CONFIG_VT_CONSOLE_SLEEP
diff --git a/kernel/reboot.c b/kernel/reboot.c
index e76e2570dcf5..f2f5c9d7caa0 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -48,13 +48,6 @@ int reboot_cpu;
enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
-/*
- * If set, this is used for preparing the system to power off.
- */
-
-void (*pm_power_off_prepare)(void);
-EXPORT_SYMBOL_GPL(pm_power_off_prepare);
-
/**
* emergency_restart - reboot the system
*
@@ -877,10 +870,6 @@ void do_kernel_power_off(void)
static void do_kernel_power_off_prepare(void)
{
- /* legacy pm_power_off_prepare() is unchained and has highest priority
*/
- if (pm_power_off_prepare)
- return pm_power_off_prepare();
-
blocking_notifier_call_chain(&power_off_handler_list, POWEROFF_PREPARE,
NULL);
}
--
2.35.1
[PATCH v7 00/20] Introduce power-off+restart call chain API
Problem --- SoC devices require power-off call chaining functionality from kernel. We have a widely used restart chaining provided by restart notifier API, but nothing for power-off. Solution Introduce new API that provides both restart and power-off call chains. Why combine restart with power-off? Because drivers often do both. More practical to have API that provides both under the same roof. The new API is designed with simplicity and extensibility in mind. It's built upon the existing restart and reboot APIs. The simplicity is in new helper functions that are convenient for drivers. The extensibility is in the design that doesn't hardcode callback arguments, making easy to add new parameters and remove old. This is a third attempt to introduce the new API. First was made by Guenter Roeck back in 2014, second was made by Thierry Reding in 2017. In fact the work didn't stop and recently arm_pm_restart() was removed from v5.14 kernel, which was a part of preparatory work started by Guenter Roeck. I took into account experience and ideas from the previous attempts, extended and polished them. Adoption plan - This patchset introduces the new API. It also converts multiple drivers and arch code to the new API to demonstrate how it all looks in practice. The plan is: 1. Merge the new API and convert arch code to use do_kernel_power_off(). For now the new API will co-exist with the older API. 2. Convert all drivers and platform code to the new API. 3. Remove obsoleted pm_power_off and pm_power_off_prepare variables. 4. Make restart-notifier API private to kernel/reboot.c once no users left. 5. Make unique-priority of the handlers' a mandatory requirement in the new API. The plan is fully implemented here: [1] https://gitlab.collabora.com/dmitry.osipenko/linux-kernel-rd/-/commits/sys-off-handler For now I'm sending the first 20 base patches out of ~180. Majority of drivers and platform patches depend on the base patches, hence the rest will come later on, once base will land. All [1] patches are compile-tested. Tegra, Rockchip and x86 ACPI patches are tested on hardware. Results --- 1. Devices can be powered off properly. 2. Global variables are removed from drivers. 3. Global pm_power_off and pm_power_off_prepare callback variables are removed once all users are converted to the new API. The latter callback is removed by patch #25 of this series. 4. Ambiguous call chain ordering is prohibited. See patch #4 which adds verification of restart handlers priorities, ensuring that they are unique. Changelog: v7: - Rebased on a recent linux-next. Dropped the recently removed NDS32 architecture. Only SH and x86 arches left un-acked. - Added acks from Thomas Bogendoerfer and Krzysztof Kozlowski to the MIPS and memory/emif patches respectively. - Made couple minor cosmetic improvements to the new API. - A month ago I joined Collabora and continuing to work on this series on the company's time, so changed my email address to collabora.com v6: - Rebased on a recent linux-next. - Made minor couple cosmetic changes. v5: - Dropped patches which cleaned up notifier/reboot headers, as was requested by Rafael Wysocki. - Dropped WARN_ON() from the code, as was requested by Rafael Wysocki. Replaced it with pr_err() appropriately. - Dropped *_notifier_has_unique_priority() functions and added *_notifier_chain_register_unique_prio() instead, as was suggested by Michał Mirosław and Rafael Wysocki. - Dropped export of blocking_notifier_call_chain_is_empty() symbol, as was suggested by Rafael Wysocki. - Michał Mirosław suggested that will be better to split up patch that adds the new API to ease reviewing, but Rafael Wysocki asked not add more patches, so I kept it as a single patch. - Added temporary "weak" stub for pm_power_off() which fixes linkage failure once symbol is removed from arch/* code. Previously I missed this problem because was only compile-testing object files. v4: - Made a very minor improvement to doc comments, clarifying couple default values. - Corrected list of emails recipient by adding Linus, Sebastian, Philipp and more NDS people. Removed bouncing emails. - Added acks that were given to v3. v3: - Renamed power_handler to sys_off_handler as was suggested by Rafael Wysocki. - Improved doc-comments as was suggested by Rafael Wysocki. Added more doc-comments. - Implemented full set of 180 patches which convert whole kernel in accordance to the plan, see link [1] above. Slightly adjusted API to better suit for the remaining converted drivers. * Added unregister_sys_off_handler() that is handy for a couple old platform drivers. * Dropped devm_register_trivial_restart_handler(), 'simple' variant is enough to have. - Improved "Add atomic/blocking_not
[PATCH v7 18/20] ACPI: power: Switch to sys-off handler API
Switch to sys-off API that replaces legacy pm_power_off callbacks.
Signed-off-by: Dmitry Osipenko
---
drivers/acpi/sleep.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index c992e57b2c79..426297258e26 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -47,19 +47,11 @@ static void acpi_sleep_tts_switch(u32 acpi_state)
}
}
-static int tts_notify_reboot(struct notifier_block *this,
- unsigned long code, void *x)
+static void tts_reboot_prepare(struct reboot_prep_data *data)
{
acpi_sleep_tts_switch(ACPI_STATE_S5);
- return NOTIFY_DONE;
}
-static struct notifier_block tts_notifier = {
- .notifier_call = tts_notify_reboot,
- .next = NULL,
- .priority = 0,
-};
-
static int acpi_sleep_prepare(u32 acpi_state)
{
#ifdef CONFIG_ACPI_SLEEP
@@ -1023,7 +1015,7 @@ static void acpi_sleep_hibernate_setup(void)
static inline void acpi_sleep_hibernate_setup(void) {}
#endif /* !CONFIG_HIBERNATION */
-static void acpi_power_off_prepare(void)
+static void acpi_power_off_prepare(struct power_off_prep_data *data)
{
/* Prepare to power off the system */
acpi_sleep_prepare(ACPI_STATE_S5);
@@ -1031,7 +1023,7 @@ static void acpi_power_off_prepare(void)
acpi_os_wait_events_complete();
}
-static void acpi_power_off(void)
+static void acpi_power_off(struct power_off_data *data)
{
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
pr_debug("%s called\n", __func__);
@@ -1039,6 +1031,11 @@ static void acpi_power_off(void)
acpi_enter_sleep_state(ACPI_STATE_S5);
}
+static struct sys_off_handler acpi_sys_off_handler = {
+ .power_off_priority = POWEROFF_PRIO_FIRMWARE,
+ .reboot_prepare_cb = tts_reboot_prepare,
+};
+
int __init acpi_sleep_init(void)
{
char supported[ACPI_S_STATE_COUNT * 3 + 1];
@@ -1055,8 +1052,8 @@ int __init acpi_sleep_init(void)
if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
sleep_states[ACPI_STATE_S5] = 1;
- pm_power_off_prepare = acpi_power_off_prepare;
- pm_power_off = acpi_power_off;
+ acpi_sys_off_handler.power_off_cb = acpi_power_off;
+ acpi_sys_off_handler.power_off_prepare_cb =
acpi_power_off_prepare;
} else {
acpi_no_s5 = true;
}
@@ -1072,6 +1069,6 @@ int __init acpi_sleep_init(void)
* Register the tts_notifier to reboot notifier list so that the _TTS
* object can also be evaluated when the system enters S5.
*/
- register_reboot_notifier(&tts_notifier);
+ register_sys_off_handler(&acpi_sys_off_handler);
return 0;
}
--
2.35.1
[PATCH v7 17/20] memory: emif: Use kernel_can_power_off()
Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/emif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index edf3ba7447ed..fa6845313a43 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -630,7 +630,7 @@ static irqreturn_t emif_threaded_isr(int irq, void *dev_id)
dev_emerg(emif->dev, "SDRAM temperature exceeds operating
limit.. Needs shut down!!!\n");
/* If we have Power OFF ability, use it, else try restarting */
- if (pm_power_off) {
+ if (kernel_can_power_off()) {
kernel_power_off();
} else {
WARN(1, "FIXME: NO pm_power_off!!! trying restart\n");
--
2.35.1
[PATCH v7 14/20] x86: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/x86/kernel/reboot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index fa700b46588e..c3636ea4aa71 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -739,10 +739,10 @@ static void native_machine_halt(void)
static void native_machine_power_off(void)
{
- if (pm_power_off) {
+ if (kernel_can_power_off()) {
if (!reboot_force)
machine_shutdown();
- pm_power_off();
+ do_kernel_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
--
2.35.1
[PATCH v7 13/20] sh: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-off-by: Dmitry Osipenko
---
arch/sh/kernel/reboot.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 5c33f036418b..e8eeedc9b182 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -46,8 +46,7 @@ static void native_machine_shutdown(void)
static void native_machine_power_off(void)
{
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
static void native_machine_halt(void)
--
2.35.1
[PATCH v7 11/20] powerpc: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Michael Ellerman
Signed-off-by: Dmitry Osipenko
---
arch/powerpc/kernel/setup-common.c | 4 +---
arch/powerpc/xmon/xmon.c | 3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 518ae5aa9410..1b586577e75b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -161,9 +161,7 @@ void machine_restart(char *cmd)
void machine_power_off(void)
{
machine_shutdown();
- if (pm_power_off)
- pm_power_off();
-
+ do_kernel_power_off();
smp_send_stop();
machine_hang();
}
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index fd72753e8ad5..c916bf250796 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1243,8 +1243,7 @@ static void bootcmds(void)
} else if (cmd == 'h') {
ppc_md.halt();
} else if (cmd == 'p') {
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
}
--
2.35.1
[PATCH v7 08/20] arm64: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Catalin Marinas
Signed-off-by: Dmitry Osipenko
---
arch/arm64/kernel/process.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 7fa97df55e3a..26d1b0a4329a 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -111,8 +111,7 @@ void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
/*
--
2.35.1
[PATCH v7 07/20] riscv: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Acked-by: Palmer Dabbelt
Signed-off-by: Dmitry Osipenko
---
arch/riscv/kernel/reset.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/kernel/reset.c b/arch/riscv/kernel/reset.c
index 9c842c41684a..912288572226 100644
--- a/arch/riscv/kernel/reset.c
+++ b/arch/riscv/kernel/reset.c
@@ -23,16 +23,12 @@ void machine_restart(char *cmd)
void machine_halt(void)
{
- if (pm_power_off != NULL)
- pm_power_off();
- else
- default_power_off();
+ do_kernel_power_off();
+ default_power_off();
}
void machine_power_off(void)
{
- if (pm_power_off != NULL)
- pm_power_off();
- else
- default_power_off();
+ do_kernel_power_off();
+ default_power_off();
}
--
2.35.1
[PATCH v7 04/20] kernel: Add combined power-off+restart handler call chain API
SoC platforms often have multiple ways of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart functionality.
The old pm_power_off method will be kept around till all users are
converted to the new API.
Current restart API will be replaced by the new unified API since
new API is its superset. The restart functionality of the sys-off handler
API is built upon the existing restart-notifier APIs.
In order to ease conversion to the new API, convenient helpers are added
for the common use-cases. They will reduce amount of boilerplate code and
remove global variables. These helpers preserve old behaviour for cases
where only one power-off handler is expected, this is what all existing
drivers want, and thus, they could be easily converted to the new API.
Users of the new API should explicitly enable power-off chaining by
setting corresponding flag of the power_handler structure.
Signed-off-by: Dmitry Osipenko
---
include/linux/reboot.h | 229 ++-
kernel/power/hibernate.c | 2 +-
kernel/reboot.c | 604 ++-
3 files changed, 827 insertions(+), 8 deletions(-)
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index a2429648d831..ba5e5dddcfcd 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -8,10 +8,35 @@
struct device;
-#define SYS_DOWN 0x0001 /* Notify of system down */
-#define SYS_RESTARTSYS_DOWN
-#define SYS_HALT 0x0002 /* Notify of system halt */
-#define SYS_POWER_OFF 0x0003 /* Notify of system power off */
+enum reboot_prepare_mode {
+ SYS_DOWN = 1, /* Notify of system down */
+ SYS_RESTART = SYS_DOWN,
+ SYS_HALT, /* Notify of system halt */
+ SYS_POWER_OFF, /* Notify of system power off */
+};
+
+/*
+ * Standard restart priority levels. Intended to be set in the
+ * sys_off_handler.restart_priority field.
+ *
+ * Use `RESTART_PRIO_ABC +- prio` style for additional levels.
+ *
+ * RESTART_PRIO_RESERVED: Falls back to RESTART_PRIO_DEFAULT.
+ * Drivers may leave priority initialized
+ * to zero, to auto-set it to the default level.
+ *
+ * RESTART_PRIO_LOW: Use this for handler of last resort.
+ *
+ * RESTART_PRIO_DEFAULT: Use this for default/generic handler.
+ *
+ * RESTART_PRIO_HIGH: Use this if you have multiple handlers and
+ * this handler has higher priority than the
+ * default handler.
+ */
+#define RESTART_PRIO_RESERVED 0
+#define RESTART_PRIO_LOW 8
+#define RESTART_PRIO_DEFAULT 128
+#define RESTART_PRIO_HIGH 192
enum reboot_mode {
REBOOT_UNDEFINED = -1,
@@ -49,6 +74,201 @@ extern int register_restart_handler(struct notifier_block
*);
extern int unregister_restart_handler(struct notifier_block *);
extern void do_kernel_restart(char *cmd);
+/*
+ * System power-off and restart API.
+ */
+
+/*
+ * Standard power-off priority levels. Intended to be set in the
+ * sys_off_handler.power_off_priority field.
+ *
+ * Use `POWEROFF_PRIO_ABC +- prio` style for additional levels.
+ *
+ * POWEROFF_PRIO_RESERVED: Falls back to POWEROFF_PRIO_DEFAULT.
+ * Drivers may leave priority initialized
+ * to zero, to auto-set it to the default level.
+ *
+ * POWEROFF_PRIO_PLATFORM: Intended to be used by platform-level handler.
+ * Has lowest priority since device drivers are
+ * expected to take over platform handler which
+ * doesn't allow further callback chaining.
+ *
+ * POWEROFF_PRIO_DEFAULT: Use this for default/generic handler.
+ *
+ * POWEROFF_PRIO_FIRMWARE: Use this if handler uses firmware call.
+ * Has highest priority since firmware is expected
+ * to know best how to power-off hardware properly.
+ */
+#define POWEROFF_PRIO_RESERVED 0
+#define POWEROFF_PRIO_PLATFORM 1
+#define POWEROFF_PRIO_DEFAULT 128
+#define POWEROFF_PRIO_HIGH 192
+#define POWEROFF_PRIO_FIRMWARE 224
+
+enum poweroff_mode {
+ POWEROFF_NORMAL = 0,
+ POWEROFF_PREPARE,
+};
+
+/**
+ * struct power_off_data - Power-off callback argument
+ *
+ * @cb_data: Callback data.
+ */
+struct power_off_data {
+ void *cb_data;
+};
+
+/**
+ * struct power_off_prep_data - Power-off preparation callback argument
+ *
+ * @cb_data: Callback data.
+ */
+struct power_off_prep_data {
+ void *cb_data;
+};
+
+/**
+ * struct restart_data - Restart callback argument
+ *
+ * @cb_data: Callback data.
+ * @cmd: Restart comma
[PATCH v7 02/20] notifier: Add atomic/blocking_notifier_chain_register_unique_prio()
Add variant of atomic/blocking_notifier_chain_register() functions that
doesn't allow to register notifier using a duplicated priority. The -EBUSY
error code is returned in this case by the new API functions.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 5 +++
kernel/notifier.c| 88 +++-
2 files changed, 74 insertions(+), 19 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d4717bc0ab85..ccce26197dd2 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -150,6 +150,11 @@ extern int raw_notifier_chain_register(struct
raw_notifier_head *nh,
extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
struct notifier_block *nb);
+extern int atomic_notifier_chain_register_unique_prio(
+ struct atomic_notifier_head *nh, struct notifier_block *nb);
+extern int blocking_notifier_chain_register_unique_prio(
+ struct blocking_notifier_head *nh, struct notifier_block *nb);
+
extern int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh,
struct notifier_block *nb);
extern int blocking_notifier_chain_unregister(struct blocking_notifier_head
*nh,
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 4ed6bda8f127..4fc32b1e6cbb 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -20,7 +20,8 @@ BLOCKING_NOTIFIER_HEAD(reboot_notifier_list);
*/
static int notifier_chain_register(struct notifier_block **nl,
- struct notifier_block *n)
+ struct notifier_block *n,
+ bool unique_priority)
{
while ((*nl) != NULL) {
if (unlikely((*nl) == n)) {
@@ -30,6 +31,8 @@ static int notifier_chain_register(struct notifier_block **nl,
}
if (n->priority > (*nl)->priority)
break;
+ if (n->priority == (*nl)->priority && unique_priority)
+ return -EBUSY;
nl = &((*nl)->next);
}
n->next = *nl;
@@ -144,12 +147,35 @@ int atomic_notifier_chain_register(struct
atomic_notifier_head *nh,
int ret;
spin_lock_irqsave(&nh->lock, flags);
- ret = notifier_chain_register(&nh->head, n);
+ ret = notifier_chain_register(&nh->head, n, false);
spin_unlock_irqrestore(&nh->lock, flags);
return ret;
}
EXPORT_SYMBOL_GPL(atomic_notifier_chain_register);
+/**
+ * atomic_notifier_chain_register_unique_prio - Add notifier to an atomic
notifier chain
+ * @nh: Pointer to head of the atomic notifier chain
+ * @n: New entry in notifier chain
+ *
+ * Adds a notifier to an atomic notifier chain if there is no other
+ * notifier registered using the same priority.
+ *
+ * Returns 0 on success, %-EEXIST or %-EBUSY on error.
+ */
+int atomic_notifier_chain_register_unique_prio(struct atomic_notifier_head *nh,
+ struct notifier_block *n)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&nh->lock, flags);
+ ret = notifier_chain_register(&nh->head, n, true);
+ spin_unlock_irqrestore(&nh->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(atomic_notifier_chain_register_unique_prio);
+
/**
* atomic_notifier_chain_unregister - Remove notifier from an atomic
notifier chain
* @nh: Pointer to head of the atomic notifier chain
@@ -209,18 +235,9 @@ NOKPROBE_SYMBOL(atomic_notifier_call_chain);
* synchronized by an rwsem.
*/
-/**
- * blocking_notifier_chain_register - Add notifier to a blocking notifier
chain
- * @nh: Pointer to head of the blocking notifier chain
- * @n: New entry in notifier chain
- *
- * Adds a notifier to a blocking notifier chain.
- * Must be called in process context.
- *
- * Returns 0 on success, %-EEXIST on error.
- */
-int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
- struct notifier_block *n)
+static int __blocking_notifier_chain_register(struct blocking_notifier_head
*nh,
+ struct notifier_block *n,
+ bool unique_priority)
{
int ret;
@@ -230,15 +247,48 @@ int blocking_notifier_chain_register(struct
blocking_notifier_head *nh,
* such times we must not call down_write().
*/
if (unlikely(system_state == SYSTEM_BOOTING))
- return notifier_chain_register(&nh->head, n);
+ return notifier_chain_register(&nh->head, n, unique_priority);
down_write(&nh->rwsem);
- ret = notifier_chain_register(&nh->head, n);
+ ret = notifier_chain_register(&nh->head, n, unique_priority);
up_write(&nh->rwsem);
return ret;
}
+
+/**
+ * blocking_notifier_chain_register - Add notifier to a bloc
[PATCH v7 01/20] notifier: Add blocking_notifier_call_chain_is_empty()
Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.
Signed-off-by: Dmitry Osipenko
---
include/linux/notifier.h | 2 ++
kernel/notifier.c| 13 +
2 files changed, 15 insertions(+)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 87069b8459af..d4717bc0ab85 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -173,6 +173,8 @@ extern int blocking_notifier_call_chain_robust(struct
blocking_notifier_head *nh
extern int raw_notifier_call_chain_robust(struct raw_notifier_head *nh,
unsigned long val_up, unsigned long val_down, void *v);
+extern bool blocking_notifier_call_chain_is_empty(struct
blocking_notifier_head *nh);
+
#define NOTIFY_DONE0x /* Don't care */
#define NOTIFY_OK 0x0001 /* Suits me */
#define NOTIFY_STOP_MASK 0x8000 /* Don't call further */
diff --git a/kernel/notifier.c b/kernel/notifier.c
index ba005ebf4730..4ed6bda8f127 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -323,6 +323,19 @@ int blocking_notifier_call_chain(struct
blocking_notifier_head *nh,
}
EXPORT_SYMBOL_GPL(blocking_notifier_call_chain);
+/**
+ * blocking_notifier_call_chain_is_empty - Check whether notifier chain is
empty
+ * @nh: Pointer to head of the blocking notifier chain
+ *
+ * Checks whether notifier chain is empty.
+ *
+ * Returns true is notifier chain is empty, false otherwise.
+ */
+bool blocking_notifier_call_chain_is_empty(struct blocking_notifier_head *nh)
+{
+ return !rcu_access_pointer(nh->head);
+}
+
/*
* Raw notifier chain routines. There is no protection;
* the caller must provide it. Use at your own risk!
--
2.35.1
[PATCH v7 05/20] ARM: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Reviewed-by: Russell King (Oracle)
Signed-off-by: Dmitry Osipenko
---
arch/arm/kernel/reboot.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 3044fcb8d073..2cb943422554 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -116,9 +116,7 @@ void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
-
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
/*
--
2.35.1
[ovmf test] 169321: regressions - FAIL
flight 169321 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169321/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 42 days 336 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days9 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169319: regressions - FAIL
flight 169319 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169319/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 42 days 335 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days8 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169317: regressions - FAIL
flight 169317 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169317/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 42 days 334 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days7 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169316: regressions - FAIL
flight 169316 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169316/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 333 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days6 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169315: regressions - FAIL
flight 169315 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169315/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 332 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days5 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169314: regressions - FAIL
flight 169314 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169314/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 331 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days4 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[xen-unstable test] 169309: tolerable FAIL - PUSHED
flight 169309 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169309/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169292 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169292 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169292 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169292 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169292 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169292 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169292 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169292 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169292 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169292 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169292 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169292 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169292 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass version
[ovmf test] 169313: regressions - FAIL
flight 169313 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169313/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 330 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days3 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
[ovmf test] 169312: regressions - FAIL
flight 169312 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169312/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 329 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days2 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..
Hi,
On 09/04/2022 02:00, Stefano Stabellini wrote:
On Wed, 23 Mar 2022, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96 +
1 file changed, 96 insertions(+)
create mode 100644 docs/designs/dom0less-evtchn.md
diff --git a/docs/designs/dom0less-evtchn.md b/docs/designs/dom0less-evtchn.md
new file mode 100644
index 00..6a1b7e8c22
--- /dev/null
+++ b/docs/designs/dom0less-evtchn.md
@@ -0,0 +1,96 @@
+# Signaling support between two domUs on dom0less system
+
+## Current state: Draft version
+
+## Proposer(s): Rahul Singh, Bertrand Marquis
+
+## Problem Statement:
+
+The goal of this work is to define a simple signaling system between Xen guests
+in dom0less systems.
+
+In dom0less system, we cannot make use of xenbus and xenstore that are used in
+normal systems with dynamic VMs to communicate between domains by providing a
+bus abstraction for paravirtualized drivers.
+
+One possible solution to implement the signaling system between domUs is based
+on event channels.
I suggest to reword this as follows:
---
Dom0less guests would benefit from a statically-defined memory sharing
and signally system for communication. One that would be immediately
available at boot without any need for dynamic configurations.
In embedded a great variety of guest operating system kernels exist,
many of which don't have support for xenstore, grant table or other
complex drivers. Some of them are small kernel-space applications (often
called "baremetal", not to be confused with the term "baremetal" used in
datacenter which means "without hypervisors") or RTOSes. Additionally,
for safety reasons, users often need to be able to configure the full
system statically so that it can be verified statically.
Event channels are very simple and can be added even to baremetal
applications. This proposal introduces a way to define them statically
to make them suitable to dom0less embedded deployments.
---
+## Proposal:
+
+Event channels are the basic primitive provided by Xen for event notifications.
+An event channel is a logical connection between 2 domains (more specifically
+between dom1,port1 and dom2,port2). They essentially store one bit of
+information, the event of interest is signalled by transitioning this bit from
+0 to 1. An event is an equivalent of a hardware interrupt.
+
+Notifications are received by a guest via an interrupt from Xen to the guest,
+indicating when an event arrives (setting the bit). Further notifications are
+masked until the bit is cleared again. When a domain wants to wait for data it
+will block until an event arrives, and then send an event to signal that data
+has been consumed. Events are delivered asynchronously to guests and are
+enqueued when the guest is not running.
+
+Event channel communication will be established statically between two domU
+guests before unpausing the domains after domain creation. Event channel
+connection information between domUs will be passed to XEN via device tree
+node.
+
+Under the /chosen node, there needs to be sub nodes with compatible
+"xen,evtchn" that descibes the event channel connection between two domUs.
+
+The event channel sub-node has the following properties:
+
+- compatible
+
+"xen,evtchn"
+
+- xen,evtchn
+
+The property is four numbers of tuples of
+(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
+
+local-port-domU1 is an integer value that will be used to allocte local
+port for domU1 to send an event notification to the remote domain.
+
+domU1-phandle is a single phandle to an domain to which local-port-domU1
+will be allocated.
+
+local-port-domU2 is an integer value that will be used to allocte local
+port for domU2 to send an event notification to the remote domain.
+
+domU2-phandle is a single phandle to an domain to which local-port-domU2
+will be allocated.
+
+Example:
+
+chosen {
+
+
+domU1: domU1 {
+..
+};
+
+domU2: domU2 {
+..
+};
+
+evtchn@1 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xa &domU1 0xb &domU2>;
+};
+
+evtchn@2 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xc &domU1 0xd &domU2>;
+};
+};
There is no need to use two evtchn nodes for this given that in device
tree it is entirely normal to have multiple tuplets in a property. Also,
it would be good to have a version number in the compatible string so
that we can change version in the future.
1)
chosen {
domU1: domU1 {
..
};
domU2: domU2 {
..
};
evtchn {
compatible = "xen,evtchn-v1";
xen,evtchn = <0xa &domU1 0xb &dom
Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..
Hi Rahul,
Title: s/../.../
On 23/03/2022 15:43, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
s/introduce/introduces/
s/the new/a/
signaling between two domUs in dom0less system.
Did you intend to add a newline before the second sentence?
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96 +
1 file changed, 96 insertions(+)
create mode 100644 docs/designs/dom0less-evtchn.md
diff --git a/docs/designs/dom0less-evtchn.md b/docs/designs/dom0less-evtchn.md
new file mode 100644
index 00..6a1b7e8c22
--- /dev/null
+++ b/docs/designs/dom0less-evtchn.md
@@ -0,0 +1,96 @@
+# Signaling support between two domUs on dom0less system
+
+## Current state: Draft version
+
+## Proposer(s): Rahul Singh, Bertrand Marquis
+
+## Problem Statement:
+
+The goal of this work is to define a simple signaling system between Xen guests
+in dom0less systems.
+
+In dom0less system, we cannot make use of xenbus and xenstore that are used in
+normal systems with dynamic VMs to communicate between domains by providing a
+bus abstraction for paravirtualized drivers.
+
+One possible solution to implement the signaling system between domUs is based
+on event channels.
+
+## Proposal:
+
+Event channels are the basic primitive provided by Xen for event notifications.
+An event channel is a logical connection between 2 domains (more specifically
+between dom1,port1 and dom2,port2). They essentially store one bit of
+information, the event of interest is signalled by transitioning this bit from
+0 to 1. An event is an equivalent of a hardware interrupt.
+
+Notifications are received by a guest via an interrupt from Xen to the guest,
+indicating when an event arrives (setting the bit).
I am a bit confused with the description. Are you trying to explain the
event channel in layman term? If not, then event channel protocol is
more complicated than that (in particular for fifo).
Further notifications are
+masked until the bit is cleared again.
I think "masked" is confusing here.
The event channel differentiate "mask" vs "pending". When sending an
event, the pending bit will be set to 1. If it wasn't already pending
and the mask bit is clear, then we will notify the guest.
If the pending bit is already set, then we will ignore.
In fact, the event channel is acting similarly to an edge interrupt. I
wrote similarly, because IIRC they are behaving slightly differently
(see [1] for more details).
When a domain wants to wait for data it
+will block until an event arrives, and then send an event to signal that data
+has been consumed.
Events are delivered asynchronously to guests and are
+enqueued when the guest is not running.
s/guest/domain/ to stay consistent and also include dom0/hardware domain.
+
+Event channel communication will be established statically between two domU
+guests before unpausing the domains after domain creation. Event channel
+connection information between domUs will be passed to XEN via device tree
+node.
Why are we limiting ourself to domUs?
+
+Under the /chosen node, there needs to be sub nodes with compatible
+"xen,evtchn" that descibes the event channel connection between two domUs.
s/descibes/describes/
+
+The event channel sub-node has the following properties:
+
+- compatible
+
+"xen,evtchn"
+
+- xen,evtchn
+
+The property is four numbers of tuples of
+(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
This is quite difficult to read. Can we add some space before/after each
comma?
+
+local-port-domU1 is an integer value that will be used to allocte local
s/allocte/allocate/
+port for domU1 to send an event notification to the remote domain.
The port will be used for sending but also receiving event notification.
Also, I would suggest to replace "remote domain" with "domU2". So it is
more explicit.
+
+domU1-phandle is a single phandle to an domain to which local-port-domU1
s/an domain/a domain/ I think.
+will be allocated.
+
+local-port-domU2 is an integer value that will be used to allocte local
s/allocte/allocate/
+port for domU2 to send an event notification to the remote domain.
Same as above for "remote domain".
+
+domU2-phandle is a single phandle to an domain to which local-port-domU2
+will be allocated.
+
+Example:
+
+chosen {
+
+
+domU1: domU1 {
+..
+};
+
+domU2: domU2 {
+..
+};
+
+evtchn@1 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xa &domU1 0xb &domU2>;
+};
+
+evtchn@2 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xc &domU1 0xd &domU2>;
+};
+};
+
+In above example two event channel comunication will be established between
+domU1 and domU2.
+
+domU1 (port 0xa) <-> domU2 (port 0xb)
+domU1
Re: [PATCH 25/27] block: add a bdev_discard_granularity helper
On Sat, Apr 09, 2022 at 06:50:41AM +0200, Christoph Hellwig wrote: > Abstract away implementation details from file systems by providing a > block_device based helper to retrieve the discard granularity. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Martin K. Petersen > Acked-by: Christoph Böhmwalder [btrfs] This is for drbd > Acked-by: Ryusuke Konishi > Acked-by: David Sterba [btrfs]
Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote: > 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 for it. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Martin K. Petersen > Acked-by: Christoph Böhmwalder [btrfs] > Acked-by: Coly Li [bcache] > --- > arch/um/drivers/ubd_kern.c | 2 -- > block/blk-core.c| 2 +- > block/blk-lib.c | 2 +- > block/blk-mq-debugfs.c | 1 - > block/ioctl.c | 3 +-- > drivers/block/drbd/drbd_main.c | 2 +- > drivers/block/drbd/drbd_nl.c| 19 ++- > drivers/block/drbd/drbd_receiver.c | 3 +-- > drivers/block/loop.c| 11 +++ > drivers/block/nbd.c | 5 + > drivers/block/null_blk/main.c | 1 - > drivers/block/rbd.c | 1 - > drivers/block/rnbd/rnbd-clt.c | 2 -- > drivers/block/rnbd/rnbd-srv-dev.h | 3 --- > drivers/block/virtio_blk.c | 2 -- > drivers/block/xen-blkback/xenbus.c | 2 +- > drivers/block/xen-blkfront.c| 2 -- > drivers/block/zram/zram_drv.c | 1 - > drivers/md/bcache/request.c | 4 ++-- > drivers/md/bcache/super.c | 3 +-- > drivers/md/bcache/sysfs.c | 2 +- > drivers/md/dm-cache-target.c| 9 + > drivers/md/dm-clone-target.c| 9 + > drivers/md/dm-log-writes.c | 3 +-- > drivers/md/dm-raid.c| 9 ++--- > drivers/md/dm-table.c | 9 ++--- > drivers/md/dm-thin.c| 11 +-- > drivers/md/dm.c | 3 +-- > drivers/md/md-linear.c | 11 +-- > drivers/md/raid0.c | 7 --- > drivers/md/raid1.c | 16 +--- > drivers/md/raid10.c | 18 ++ > drivers/md/raid5-cache.c| 2 +- > drivers/md/raid5.c | 12 > drivers/mmc/core/queue.c| 1 - > drivers/mtd/mtd_blkdevs.c | 1 - > drivers/nvme/host/core.c| 6 ++ > drivers/s390/block/dasd_fba.c | 1 - > drivers/scsi/sd.c | 2 -- > drivers/target/target_core_device.c | 2 +- For > fs/btrfs/extent-tree.c | 4 ++-- > fs/btrfs/ioctl.c| 2 +- Acked-by: David Sterba
Re: [PATCH 08/27] btrfs: use bdev_max_active_zones instead of open coding it
On Sat, Apr 09, 2022 at 06:50:24AM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > Reviewed-by: Johannes Thumshirn Acked-by: David Sterba
[ovmf test] 169311: regressions - FAIL
flight 169311 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169311/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 12a50c9ce117b6106c92bb965799e709547d8494 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 328 attempts Testing same since 169311 2022-04-11 15:43:02 Z0 days1 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4890 lines long.)
Re: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen build
> From: Anthony PERARD > Sent: Tuesday, March 22, 2022 11:22 AM > To: xen-devel@lists.xenproject.org > Cc: Anthony Perard ; Jan Beulich > ; Daniel P . Smith ; Julien > Grall ; Andrew Cooper ; George > Dunlap ; Julien Grall ; Stefano > Stabellini ; Wei Liu ; Roger Pau Monne > ; Konrad Rzeszutek Wilk ; Ross > Lagerwall ; Daniel De Graaf > Subject: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen > build > > This implement out-of-tree support, there's two ways to create an > out-of-tree build tree (after that, `make` in that new directory > works): > make O=build > mkdir build; cd build; make -f ../Makefile > also works with an absolute path for both. > > This implementation only works if the source tree is clean, as we use > VPATH. > > This patch copies most new code with handling out-of-tree build from > Linux v5.12. > > Signed-off-by: Anthony PERARD > Acked-by: Jan Beulich > Reviewed-by: Daniel P. Smith > Acked-by: Julien Grall > Tested-by: Julien Grall > Acked-by: Ross Lagerwall (livepatch parts)
Ping: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen build
Hi Ross,
Could you also ack this livpatch change?
Thanks.
On Tue, Mar 22, 2022 at 11:22:38AM +, Anthony PERARD wrote:
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdir build; cd build; make -f ../Makefile
> also works with an absolute path for both.
>
> This implementation only works if the source tree is clean, as we use
> VPATH.
>
> This patch copies most new code with handling out-of-tree build from
> Linux v5.12.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Jan Beulich
> Reviewed-by: Daniel P. Smith
> Acked-by: Julien Grall
> Tested-by: Julien Grall
> ---
[...]
> diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
> index ddb07371315e..c258ab0b5940 100644
> --- a/xen/test/livepatch/Makefile
> +++ b/xen/test/livepatch/Makefile
> @@ -11,6 +11,8 @@ endif
> CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
>
> +CFLAGS-y += -iquote $(obj)
> +
> extra-y += xen_hello_world.livepatch
> xen_hello_world-objs := xen_hello_world_func.o xen_hello_world.o note.o
> xen_note.o modinfo.o
> $(obj)/xen_hello_world.o: $(obj)/config.h
--
Anthony PERARD
Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..
Hello David,
Thanks for reviewing the design and sorry for the late reply.
> On 24 Mar 2022, at 12:24 pm, David Vrabel wrote:
>
>
>
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>> Signed-off-by: Rahul Singh
>> ---
>> docs/designs/dom0less-evtchn.md | 96 +
>> 1 file changed, 96 insertions(+)
>> create mode 100644 docs/designs/dom0less-evtchn.md
>> diff --git a/docs/designs/dom0less-evtchn.md
>> b/docs/designs/dom0less-evtchn.md
>> new file mode 100644
>> index 00..6a1b7e8c22
>> --- /dev/null
>> +++ b/docs/designs/dom0less-evtchn.md
>> @@ -0,0 +1,96 @@
>> +# Signaling support between two domUs on dom0less system
>> +
>> +## Current state: Draft version
>> +
>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>> +
>> +## Problem Statement:
>> +
>> +The goal of this work is to define a simple signaling system between Xen
>> guests
>> +in dom0less systems.
>> +
>> +In dom0less system, we cannot make use of xenbus and xenstore that are used
>> in
>> +normal systems with dynamic VMs to communicate between domains by providing
>> a
>> +bus abstraction for paravirtualized drivers.
>> +
>> +One possible solution to implement the signaling system between domUs is
>> based
>> +on event channels.
>
> This problem statement could do with some example use cases that are usefully
> solved by this proposed solution.
>
> "We don't have xenstore so can't set up shared rings, but here's a
> replacement comms mechanism that can do a single bit." Doesn't seem very
> compelling to me.
Ok. Let me add more information in next version.
>
>> + chosen {
>> +
>> +
>> + domU1: domU1 {
>> + ..
>> + };
>> +
>> + domU2: domU2 {
>> + ..
>> + };
>> +
>> + evtchn@1 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xa &domU1 0xb &domU2>;
>> + };
>> +
>> + evtchn@2 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xc &domU1 0xd &domU2>;
>> + };
>
> How is the domain supposed to know what these event channels are for?
As we are statically defining the event channel in XEN, we can document the
event
channel connection information for the end-user in the end-user documentation
and
let the user decide how he is going to use it.
>
> I'm not that familiar with device tree. Is it possible to give these entries
> name?
As per the device-tree specification, each node in the device tree is named
according to the following convention
node-name@unit-address
We can give the name to these entries but in another email, we are discussing
having singe node, in that
case there is no need to give a name.
evtchn {
compatible = "xen,evtchn-v1”;
xen,evtchn = <0xa &domU1 0xb &domU2 0xc &domU1 0xd &domU2>;
};
Regards.
Rahul
>
> David
Re: [PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time
On 11.04.2022 17:20, Luca Fancellu wrote: > Introduce a way to create different cpupools at boot time, this is > particularly useful on ARM big.LITTLE system where there might be the > need to have different cpupools for each type of core, but also > systems using NUMA can have different cpu pools for each node. > > The feature on arm relies on a specification of the cpupools from the > device tree to build pools and assign cpus to them. > > ACPI is not supported for this feature. > > With this patch, cpupool0 can now have less cpus than the number of > online ones, so update the default case for opt_dom0_max_vcpus. > > Documentation is created to explain the feature. > > Signed-off-by: Luca Fancellu > --- > Changes in v7: > - rename xen/common/boot_cpupools.c to xen/common/sched/boot-cpupool.c (Jan) > - reverted xen/common/Makefile, add entry in xen/common/sched/Makefile > - changed line in MAINTAINERS under CPU POOLS section (Dario) > - Fix documentation, update opt_dom0_max_vcpus to the number of cpu in > cpupool0 (Julien) > Changes in v6: > - Changed docs, return if booted with ACPI in btcpupools_dtb_parse, > panic if /chosen does not exists. Changed commit message (Julien) > - Add Juergen R-by for the xen/common/sched part that didn't change > Changes in v5: > - Fixed wrong variable name, swapped schedulers, add scheduler info > in the printk (Stefano) > - introduce assert in cpupool_init and btcpupools_get_cpupool_id to > harden the code > Changes in v4: > - modify Makefile to put in *.init.o, fixed stubs and macro (Jan) > - fixed docs, fix brakets (Stefano) > - keep cpu0 in Pool-0 (Julien) > - moved printk from btcpupools_allocate_pools to > btcpupools_get_cpupool_id > - Add to docs constraint about cpu0 and Pool-0 > Changes in v3: > - Add newline to cpupools.txt and removed "default n" from Kconfig (Jan) > - Fixed comment, moved defines, used global cpu_online_map, use > HAS_DEVICE_TREE instead of ARM and place arch specific code in header > (Juergen) > - Fix brakets, x86 code only panic, get rid of scheduler dt node, don't > save pool pointer and look for it from the pool list (Stefano) > - Changed data structures to allow modification to the code. > Changes in v2: > - Move feature to common code (Juergen) > - Try to decouple dtb parse and cpupool creation to allow > more way to specify cpupools (for example command line) > - Created standalone dt node for the scheduler so it can > be used in future work to set scheduler specific > parameters > - Use only auto generated ids for cpupools > --- > MAINTAINERS| 2 +- > docs/misc/arm/device-tree/cpupools.txt | 140 + > xen/arch/arm/domain_build.c| 5 +- > xen/arch/arm/include/asm/smp.h | 3 + > xen/common/Kconfig | 7 + For consistency, should the addition here - with ... > xen/common/sched/Makefile | 1 + > xen/common/sched/boot-cpupool.c| 207 + > xen/common/sched/cpupool.c | 12 +- ... the new file now under sched/, also be put in sched/Kconfig? Jan
[ovmf test] 169310: regressions - FAIL
flight 169310 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169310/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 327 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 16 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..
Hi Stefano,
Thanks for reviewing the design.
> On 9 Apr 2022, at 2:00 am, Stefano Stabellini wrote:
>
> On Wed, 23 Mar 2022, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>>
>> Signed-off-by: Rahul Singh
>> ---
>> docs/designs/dom0less-evtchn.md | 96 +
>> 1 file changed, 96 insertions(+)
>> create mode 100644 docs/designs/dom0less-evtchn.md
>>
>> diff --git a/docs/designs/dom0less-evtchn.md
>> b/docs/designs/dom0less-evtchn.md
>> new file mode 100644
>> index 00..6a1b7e8c22
>> --- /dev/null
>> +++ b/docs/designs/dom0less-evtchn.md
>> @@ -0,0 +1,96 @@
>> +# Signaling support between two domUs on dom0less system
>> +
>> +## Current state: Draft version
>> +
>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>> +
>> +## Problem Statement:
>> +
>> +The goal of this work is to define a simple signaling system between Xen
>> guests
>> +in dom0less systems.
>> +
>> +In dom0less system, we cannot make use of xenbus and xenstore that are used
>> in
>> +normal systems with dynamic VMs to communicate between domains by providing
>> a
>> +bus abstraction for paravirtualized drivers.
>> +
>> +One possible solution to implement the signaling system between domUs is
>> based
>> +on event channels.
>
> I suggest to reword this as follows:
>
> ---
> Dom0less guests would benefit from a statically-defined memory sharing
> and signally system for communication. One that would be immediately
> available at boot without any need for dynamic configurations.
>
> In embedded a great variety of guest operating system kernels exist,
> many of which don't have support for xenstore, grant table or other
> complex drivers. Some of them are small kernel-space applications (often
> called "baremetal", not to be confused with the term "baremetal" used in
> datacenter which means "without hypervisors") or RTOSes. Additionally,
> for safety reasons, users often need to be able to configure the full
> system statically so that it can be verified statically.
>
> Event channels are very simple and can be added even to baremetal
> applications. This proposal introduces a way to define them statically
> to make them suitable to dom0less embedded deployments.
> ---
>
Ok. This is really a good explanation I will add this in next version.
>
>> +## Proposal:
>> +
>> +Event channels are the basic primitive provided by Xen for event
>> notifications.
>> +An event channel is a logical connection between 2 domains (more
>> specifically
>> +between dom1,port1 and dom2,port2). They essentially store one bit of
>> +information, the event of interest is signalled by transitioning this bit
>> from
>> +0 to 1. An event is an equivalent of a hardware interrupt.
>> +
>> +Notifications are received by a guest via an interrupt from Xen to the
>> guest,
>> +indicating when an event arrives (setting the bit). Further notifications
>> are
>> +masked until the bit is cleared again. When a domain wants to wait for data
>> it
>> +will block until an event arrives, and then send an event to signal that
>> data
>> +has been consumed. Events are delivered asynchronously to guests and are
>> +enqueued when the guest is not running.
>> +
>> +Event channel communication will be established statically between two domU
>> +guests before unpausing the domains after domain creation. Event channel
>> +connection information between domUs will be passed to XEN via device tree
>> +node.
>> +
>> +Under the /chosen node, there needs to be sub nodes with compatible
>> +"xen,evtchn" that descibes the event channel connection between two domUs.
>> +
>> +The event channel sub-node has the following properties:
>> +
>> +- compatible
>> +
>> + "xen,evtchn"
>> +
>> +- xen,evtchn
>> +
>> + The property is four numbers of tuples of
>> + (local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
>> +
>> + local-port-domU1 is an integer value that will be used to allocte local
>> + port for domU1 to send an event notification to the remote domain.
>> +
>> + domU1-phandle is a single phandle to an domain to which local-port-domU1
>> + will be allocated.
>> +
>> + local-port-domU2 is an integer value that will be used to allocte local
>> + port for domU2 to send an event notification to the remote domain.
>> +
>> + domU2-phandle is a single phandle to an domain to which local-port-domU2
>> + will be allocated.
>> +
>> +Example:
>> +
>> + chosen {
>> +
>> +
>> + domU1: domU1 {
>> + ..
>> + };
>> +
>> + domU2: domU2 {
>> + ..
>> + };
>> +
>> + evtchn@1 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xa &domU1 0xb &domU2>;
>> + };
>> +
>> + evtchn@2 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xc &domU1 0xd &domU2>;
>> + };
>> + };
>
> There is no need to use two evtchn nodes for this given that in device
> tree it is entirely normal to have multiple tuplets in a property. Also,
> it would be good
[PATCH v7 7/7] xen/cpupool: Allow cpupool0 to use different scheduler
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is possible to allocate a different scheduler for
the cpupool0 when using the boot time cpupool.
To achieve this the hardcoded behavior in cpupool_create is removed
and the cpupool0 creation is moved.
When compiling without boot time cpupools enabled, the current
behavior is maintained (except that cpupool0 scheduler memory will be
allocated).
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
---
Changes in v7:
- no changes
Changes in v6:
- Add R-by
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- fix typo in commit message (Juergen)
- rebase changes
Changes in v2:
- new patch
---
xen/common/sched/boot-cpupool.c | 5 -
xen/common/sched/cpupool.c | 8 +---
xen/include/xen/sched.h | 5 -
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
index 240bae4cebb8..5955e6f9a98b 100644
--- a/xen/common/sched/boot-cpupool.c
+++ b/xen/common/sched/boot-cpupool.c
@@ -205,8 +205,11 @@ void __init btcpupools_allocate_pools(void)
if ( add_extra_cpupool )
next_pool_id++;
+/* Keep track of cpupool id 0 with the global cpupool0 */
+cpupool0 = cpupool_create_pool(0, pool_sched_map[0]);
+
/* Create cpupools with selected schedulers */
-for ( i = 0; i < next_pool_id; i++ )
+for ( i = 1; i < next_pool_id; i++ )
cpupool_create_pool(i, pool_sched_map[i]);
}
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 0a93bcc631bf..f6e3d97e5288 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -312,10 +312,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
c->cpupool_id = q->cpupool_id + 1;
}
-if ( poolid == 0 )
-c->sched = scheduler_get_default();
-else
-c->sched = scheduler_alloc(sched_id);
+c->sched = scheduler_alloc(sched_id);
if ( IS_ERR(c->sched) )
{
ret = PTR_ERR(c->sched);
@@ -1248,9 +1245,6 @@ static int __init cf_check cpupool_init(void)
cpupool_hypfs_init();
-cpupool0 = cpupool_create(0, 0);
-BUG_ON(IS_ERR(cpupool0));
-cpupool_put(cpupool0);
register_cpu_notifier(&cpu_nfb);
btcpupools_dtb_parse();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 32d2a6294b6d..6040fa3b3830 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1191,7 +1191,10 @@ void btcpupools_dtb_parse(void);
int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
-static inline void btcpupools_allocate_pools(void) {}
+static inline void btcpupools_allocate_pools(void)
+{
+cpupool0 = cpupool_create_pool(0, -1);
+}
static inline void btcpupools_dtb_parse(void) {}
static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
{
--
2.17.1
[PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time
Introduce a way to create different cpupools at boot time, this is particularly useful on ARM big.LITTLE system where there might be the need to have different cpupools for each type of core, but also systems using NUMA can have different cpu pools for each node. The feature on arm relies on a specification of the cpupools from the device tree to build pools and assign cpus to them. ACPI is not supported for this feature. With this patch, cpupool0 can now have less cpus than the number of online ones, so update the default case for opt_dom0_max_vcpus. Documentation is created to explain the feature. Signed-off-by: Luca Fancellu --- Changes in v7: - rename xen/common/boot_cpupools.c to xen/common/sched/boot-cpupool.c (Jan) - reverted xen/common/Makefile, add entry in xen/common/sched/Makefile - changed line in MAINTAINERS under CPU POOLS section (Dario) - Fix documentation, update opt_dom0_max_vcpus to the number of cpu in cpupool0 (Julien) Changes in v6: - Changed docs, return if booted with ACPI in btcpupools_dtb_parse, panic if /chosen does not exists. Changed commit message (Julien) - Add Juergen R-by for the xen/common/sched part that didn't change Changes in v5: - Fixed wrong variable name, swapped schedulers, add scheduler info in the printk (Stefano) - introduce assert in cpupool_init and btcpupools_get_cpupool_id to harden the code Changes in v4: - modify Makefile to put in *.init.o, fixed stubs and macro (Jan) - fixed docs, fix brakets (Stefano) - keep cpu0 in Pool-0 (Julien) - moved printk from btcpupools_allocate_pools to btcpupools_get_cpupool_id - Add to docs constraint about cpu0 and Pool-0 Changes in v3: - Add newline to cpupools.txt and removed "default n" from Kconfig (Jan) - Fixed comment, moved defines, used global cpu_online_map, use HAS_DEVICE_TREE instead of ARM and place arch specific code in header (Juergen) - Fix brakets, x86 code only panic, get rid of scheduler dt node, don't save pool pointer and look for it from the pool list (Stefano) - Changed data structures to allow modification to the code. Changes in v2: - Move feature to common code (Juergen) - Try to decouple dtb parse and cpupool creation to allow more way to specify cpupools (for example command line) - Created standalone dt node for the scheduler so it can be used in future work to set scheduler specific parameters - Use only auto generated ids for cpupools --- MAINTAINERS| 2 +- docs/misc/arm/device-tree/cpupools.txt | 140 + xen/arch/arm/domain_build.c| 5 +- xen/arch/arm/include/asm/smp.h | 3 + xen/common/Kconfig | 7 + xen/common/sched/Makefile | 1 + xen/common/sched/boot-cpupool.c| 207 + xen/common/sched/cpupool.c | 12 +- xen/include/xen/sched.h| 14 ++ 9 files changed, 388 insertions(+), 3 deletions(-) create mode 100644 docs/misc/arm/device-tree/cpupools.txt create mode 100644 xen/common/sched/boot-cpupool.c diff --git a/MAINTAINERS b/MAINTAINERS index 6a097b43eb9a..7963c9232c07 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -274,7 +274,7 @@ CPU POOLS M: Juergen Gross M: Dario Faggioli S: Supported -F: xen/common/sched/cpupool.c +F: xen/common/sched/*cpupool.c DEVICE TREE M: Stefano Stabellini diff --git a/docs/misc/arm/device-tree/cpupools.txt b/docs/misc/arm/device-tree/cpupools.txt new file mode 100644 index ..1f640d680317 --- /dev/null +++ b/docs/misc/arm/device-tree/cpupools.txt @@ -0,0 +1,140 @@ +Boot time cpupools +== + +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to +create cpupools during boot phase by specifying them in the device tree. +ACPI is not supported for this feature. + +Cpupools specification nodes shall be direct childs of /chosen node. +Each cpupool node contains the following properties: + +- compatible (mandatory) + +Must always include the compatiblity string: "xen,cpupool". + +- cpupool-cpus (mandatory) + +Must be a list of device tree phandle to nodes describing cpus (e.g. having +device_type = "cpu"), it can't be empty. + +- cpupool-sched (optional) + +Must be a string having the name of a Xen scheduler. Check the sched=<...> +boot argument for allowed values [1]. When this property is omitted, the Xen +default scheduler will be used. + + +Constraints +=== + +If no cpupools are specified, all cpus will be assigned to one cpupool +implicitly created (Pool-0). + +If cpupools node are specified, but not every cpu brought up by Xen is assigned, +all the not assigned cpu will be assigned to an additional cpupool. + +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will +stop. + +The boot cpu must be assigned to Pool-0, so the cpupool containing that core +will become Pool-0 automatically. + + +Examples + + +A system having two t
[PATCH v7 3/7] xen/sched: retrieve scheduler id by name
Add a static function to retrieve the scheduler pointer using the
scheduler name.
Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.
Take the occasion to replace open coded scheduler search with the
new static function in scheduler_init.
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
Reviewed-by: Dario Faggioli
---
Changes in v7:
- Add R-by (Dario)
Changes in v6:
- no changes
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- add R-by
Changes in v2:
- replace open coded scheduler search in scheduler_init (Juergen)
---
xen/common/sched/core.c | 40 ++--
xen/include/xen/sched.h | 11 +++
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 19ab67818106..48ee01420fb8 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2947,10 +2947,30 @@ void scheduler_enable(void)
scheduler_active = true;
}
+static inline
+const struct scheduler *__init sched_get_by_name(const char *sched_name)
+{
+unsigned int i;
+
+for ( i = 0; i < NUM_SCHEDULERS; i++ )
+if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
+return schedulers[i];
+
+return NULL;
+}
+
+int __init sched_get_id_by_name(const char *sched_name)
+{
+const struct scheduler *scheduler = sched_get_by_name(sched_name);
+
+return scheduler ? scheduler->sched_id : -1;
+}
+
/* Initialise the data structures. */
void __init scheduler_init(void)
{
struct domain *idle_domain;
+const struct scheduler *scheduler;
int i;
scheduler_enable();
@@ -2981,25 +3001,17 @@ void __init scheduler_init(void)
schedulers[i]->opt_name);
schedulers[i] = NULL;
}
-
-if ( schedulers[i] && !ops.name &&
- !strcmp(schedulers[i]->opt_name, opt_sched) )
-ops = *schedulers[i];
}
-if ( !ops.name )
+scheduler = sched_get_by_name(opt_sched);
+if ( !scheduler )
{
printk("Could not find scheduler: %s\n", opt_sched);
-for ( i = 0; i < NUM_SCHEDULERS; i++ )
-if ( schedulers[i] &&
- !strcmp(schedulers[i]->opt_name, CONFIG_SCHED_DEFAULT) )
-{
-ops = *schedulers[i];
-break;
-}
-BUG_ON(!ops.name);
-printk("Using '%s' (%s)\n", ops.name, ops.opt_name);
+scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
+BUG_ON(!scheduler);
+printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
}
+ops = *scheduler;
if ( cpu_schedule_up(0) )
BUG();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0164db996b8b..4442a1940c25 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -764,6 +764,17 @@ void sched_destroy_domain(struct domain *d);
long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
long sched_adjust_global(struct xen_sysctl_scheduler_op *);
int sched_id(void);
+
+/*
+ * sched_get_id_by_name - retrieves a scheduler id given a scheduler name
+ * @sched_name: scheduler name as a string
+ *
+ * returns:
+ * positive value being the scheduler id, on success
+ * negative value if the scheduler name is not found.
+ */
+int sched_get_id_by_name(const char *sched_name);
+
void vcpu_wake(struct vcpu *v);
long vcpu_yield(void);
void vcpu_sleep_nosync(struct vcpu *v);
--
2.17.1
[PATCH v7 1/7] tools/cpupools: Give a name to unnamed cpupools
With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.
Given the change, remove the check for poolid == 0 from
libxl_cpupoolid_to_name(...).
Signed-off-by: Luca Fancellu
Reviewed-by: Anthony PERARD
---
Changes in v7:
- Add R-by from Anthony
Changes in v6:
- Reworked loop to have only one error path (Anthony)
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- no changes, add R-by
Changes in v2:
- Remove unused variable, moved xc_cpupool_infofree
ahead to simplify the code, use asprintf (Juergen)
---
tools/helpers/xen-init-dom0.c | 37 +-
tools/libs/light/libxl_utils.c | 3 +--
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
index c99224a4b607..37eff8868f25 100644
--- a/tools/helpers/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -43,7 +43,10 @@ int main(int argc, char **argv)
int rc;
struct xs_handle *xsh = NULL;
xc_interface *xch = NULL;
-char *domname_string = NULL, *domid_string = NULL;
+char *domname_string = NULL, *domid_string = NULL,
+ *pool_path = NULL, *pool_name = NULL;
+xc_cpupoolinfo_t *xcinfo;
+unsigned int pool_id = 0;
libxl_uuid uuid;
/* Accept 0 or 1 argument */
@@ -114,9 +117,41 @@ int main(int argc, char **argv)
goto out;
}
+/* Create an entry in xenstore for each cpupool on the system */
+do {
+xcinfo = xc_cpupool_getinfo(xch, pool_id);
+if (xcinfo != NULL) {
+if (xcinfo->cpupool_id != pool_id)
+pool_id = xcinfo->cpupool_id;
+xc_cpupool_infofree(xch, xcinfo);
+if (asprintf(&pool_path, "/local/pool/%d/name", pool_id) <= 0) {
+fprintf(stderr, "cannot allocate memory for pool path\n");
+rc = 1;
+goto out;
+}
+if (asprintf(&pool_name, "Pool-%d", pool_id) <= 0) {
+fprintf(stderr, "cannot allocate memory for pool name\n");
+rc = 1;
+goto out;
+}
+pool_id++;
+if (!xs_write(xsh, XBT_NULL, pool_path, pool_name,
+ strlen(pool_name))) {
+fprintf(stderr, "cannot set pool name\n");
+rc = 1;
+goto out;
+}
+free(pool_name);
+free(pool_path);
+pool_path = pool_name = NULL;
+}
+} while(xcinfo != NULL);
+
printf("Done setting up Dom0\n");
out:
+free(pool_path);
+free(pool_name);
free(domid_string);
free(domname_string);
xs_close(xsh);
diff --git a/tools/libs/light/libxl_utils.c b/tools/libs/light/libxl_utils.c
index b91c2cafa223..81780da3ff40 100644
--- a/tools/libs/light/libxl_utils.c
+++ b/tools/libs/light/libxl_utils.c
@@ -151,8 +151,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t
poolid)
snprintf(path, sizeof(path), "/local/pool/%d/name", poolid);
s = xs_read(ctx->xsh, XBT_NULL, path, &len);
-if (!s && (poolid == 0))
-return strdup("Pool-0");
+
return s;
}
--
2.17.1
[PATCH v7 6/7] arm/dom0less: assign dom0less guests to cpupools
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.
Add member to the xen_domctl_createdomain public interface so the
XEN_DOMCTL_INTERFACE_VERSION version is bumped.
Add public function to retrieve a pool id from the device tree
cpupool node.
Update documentation about the property.
Signed-off-by: Luca Fancellu
Reviewed-by: Stefano Stabellini
---
Changes in v7:
- Add comment for cpupool_id struct member. (Jan)
Changes in v6:
- no changes
Changes in v5:
- no changes
Changes in v4:
- no changes
- add R-by
Changes in v3:
- Use explicitely sized integer for struct xen_domctl_createdomain
cpupool_id member. (Stefano)
- Changed code due to previous commit code changes
Changes in v2:
- Moved cpupool_id from arch specific to common part (Juergen)
- Implemented functions to retrieve the cpupool id from the
cpupool dtb node.
---
docs/misc/arm/device-tree/booting.txt | 5 +
xen/arch/arm/domain_build.c | 14 +-
xen/common/domain.c | 2 +-
xen/common/sched/boot-cpupool.c | 24
xen/include/public/domctl.h | 5 -
xen/include/xen/sched.h | 9 +
6 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index a94125394e35..7b4a29a2c293 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -188,6 +188,11 @@ with the following properties:
An empty property to request the memory of the domain to be
direct-map (guest physical address == physical address).
+- domain-cpupool
+
+Optional. Handle to a xen,cpupool device tree node that identifies the
+cpupool where the guest will be started at boot.
+
Under the "xen,domain" compatible node, one or more sub-nodes are present
for the DomU kernel and ramdisk.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9aa6ae27c40f..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3175,7 +3175,8 @@ static int __init construct_domU(struct domain *d,
void __init create_domUs(void)
{
struct dt_device_node *node;
-const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+const struct dt_device_node *cpupool_node,
+*chosen = dt_find_node_by_path("/chosen");
BUG_ON(chosen == NULL);
dt_for_each_child_node(chosen, node)
@@ -3244,6 +3245,17 @@ void __init create_domUs(void)
vpl011_virq - 32 + 1);
}
+/* Get the optional property domain-cpupool */
+cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+if ( cpupool_node )
+{
+int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+if ( pool_id < 0 )
+panic("Error getting cpupool id from domain-cpupool (%d)\n",
+ pool_id);
+d_cfg.cpupool_id = pool_id;
+}
+
/*
* The variable max_init_domid is initialized with zero, so here it's
* very important to use the pre-increment operator to call
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b239..0827400f4f49 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -698,7 +698,7 @@ struct domain *domain_create(domid_t domid,
if ( !d->pbuf )
goto fail;
-if ( (err = sched_init_domain(d, 0)) != 0 )
+if ( (err = sched_init_domain(d, config->cpupool_id)) != 0 )
goto fail;
if ( (err = late_hwdom_init(d)) != 0 )
diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
index 9429a5025fc4..240bae4cebb8 100644
--- a/xen/common/sched/boot-cpupool.c
+++ b/xen/common/sched/boot-cpupool.c
@@ -22,6 +22,8 @@ static unsigned int __initdata next_pool_id;
#define BTCPUPOOLS_DT_NODE_NO_REG (-1)
#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
+#define BTCPUPOOLS_DT_WRONG_NODE (-3)
+#define BTCPUPOOLS_DT_CORRUPTED_NODE (-4)
static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
{
@@ -56,6 +58,28 @@ get_logical_cpu_from_cpu_node(const struct dt_device_node
*cpu_node)
return cpu_num;
}
+int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+const struct dt_device_node *phandle_node;
+int cpu_num;
+
+if ( !dt_device_is_compatible(node, "xen,cpupool") )
+return BTCPUPOOLS_DT_WRONG_NODE;
+/*
+ * Get first cpu listed in the cpupool, from its reg it's possible to
+ * retrieve the cpupool id.
+ */
+phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
+if ( !phandle_node )
+return BTCPUPOOLS_DT_CORRUPTED_NODE;
+
+cpu_num = get_logical
[PATCH v7 5/7] xen/cpupool: Don't allow removing cpu0 from cpupool0
Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
might not work in a sane way.
Signed-off-by: Luca Fancellu
---
Changes in v7:
- new patch
---
xen/common/sched/cpupool.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 86a175f99cd5..0a93bcc631bf 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -572,6 +572,7 @@ static long cf_check cpupool_unassign_cpu_helper(void *info)
* possible failures:
* - last cpu and still active domains in cpupool
* - cpu just being unplugged
+ * - Attempt to remove boot cpu from cpupool0
*/
static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
{
@@ -582,7 +583,12 @@ static int cpupool_unassign_cpu(struct cpupool *c,
unsigned int cpu)
debugtrace_printk("cpupool_unassign_cpu(pool=%u,cpu=%d)\n",
c->cpupool_id, cpu);
-if ( !cpu_online(cpu) )
+/*
+ * Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
+ * between cpupools, cpu hotplug, destroying cpupools, shutdown of the
host,
+ * might not work in a sane way.
+ */
+if ( (!c->cpupool_id && !cpu) || !cpu_online(cpu) )
return -EINVAL;
master_cpu = sched_get_resource_cpu(cpu);
--
2.17.1
[PATCH v7 2/7] xen/sched: create public function for cpupools creation
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
Reviewed-by: Juergen Gross
---
Changes in v7:
- no changes
Changes in v6:
- add R-by
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- Fixed comment (Andrew)
Changes in v2:
- cpupool_create_pool doesn't check anymore for pool id uniqueness
before calling cpupool_create. Modified commit message accordingly
---
xen/common/sched/cpupool.c | 15 +++
xen/include/xen/sched.h| 16
2 files changed, 31 insertions(+)
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index a6da4970506a..89a891af7076 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -1219,6 +1219,21 @@ static void cpupool_hypfs_init(void)
#endif /* CONFIG_HYPFS */
+struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
+{
+struct cpupool *pool;
+
+if ( sched_id < 0 )
+sched_id = scheduler_get_default()->sched_id;
+
+pool = cpupool_create(pool_id, sched_id);
+
+BUG_ON(IS_ERR(pool));
+cpupool_put(pool);
+
+return pool;
+}
+
static int __init cf_check cpupool_init(void)
{
unsigned int cpu;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ed8539f6d297..0164db996b8b 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1153,6 +1153,22 @@ int cpupool_move_domain(struct domain *d, struct cpupool
*c);
int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
unsigned int cpupool_get_id(const struct domain *d);
const cpumask_t *cpupool_valid_cpus(const struct cpupool *pool);
+
+/*
+ * cpupool_create_pool - Creates a cpupool
+ * @pool_id: id of the pool to be created
+ * @sched_id: id of the scheduler to be used for the pool
+ *
+ * Creates a cpupool with pool_id id.
+ * The sched_id parameter identifies the scheduler to be used, if it is
+ * negative, the default scheduler of Xen will be used.
+ *
+ * returns:
+ * pointer to the struct cpupool just created, or Xen will panic in case of
+ * error
+ */
+struct cpupool *cpupool_create_pool(unsigned int pool_id, int sched_id);
+
extern void cf_check dump_runq(unsigned char key);
void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
--
2.17.1
[PATCH v7 0/7] Boot time cpupools
This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign a
dom0less guest to a cpupool at boot time.
Here follows an example, Xen is built with CONFIG_BOOT_TIME_CPUPOOLS=y.
>From the DT:
[...]
a72_0: cpu@0 {
compatible = "arm,cortex-a72";
reg = <0x0 0x0>;
device_type = "cpu";
[...]
};
a72_1: cpu@1 {
compatible = "arm,cortex-a72";
reg = <0x0 0x1>;
device_type = "cpu";
[...]
};
a53_0: cpu@100 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
[...]
};
a53_1: cpu@101 {
compatible = "arm,cortex-a53";
reg = <0x0 0x101>;
device_type = "cpu";
[...]
};
a53_2: cpu@102 {
compatible = "arm,cortex-a53";
reg = <0x0 0x102>;
device_type = "cpu";
[...]
};
a53_3: cpu@103 {
compatible = "arm,cortex-a53";
reg = <0x0 0x103>;
device_type = "cpu";
[...]
};
chosen {
#size-cells = <0x1>;
#address-cells = <0x1>;
xen,dom0-bootargs = "...";
xen,xen-bootargs = "...";
cpupool0 {
compatible = "xen,cpupool";
cpupool-cpus = <&a72_0 &a72_1>;
cpupool-sched = "credit2";
};
cp1: cpupool1 {
compatible = "xen,cpupool";
cpupool-cpus = <&a53_0 &a53_1 &a53_2 &a53_3>;
cpupool-sched = "null";
};
module@0 {
reg = <0x8008 0x130>;
compatible = "multiboot,module";
};
domU1 {
#size-cells = <0x1>;
#address-cells = <0x1>;
compatible = "xen,domain";
cpus = <1>;
memory = <0 0xC>;
vpl011;
domain-cpupool = <&cp1>;
module@9200 {
compatible = "multiboot,kernel", "multiboot,module";
reg = <0x9200 0x1ff>;
bootargs = "...";
};
};
};
[...]
The example DT is instructing Xen to have two cpu pools, one having two phisical
cpus and the one having 4 phisical cpus, the last mentioned cpu pool uses the
null scheduler and from the /chosen node we can see that a dom0less guest will
be started on that cpu pool.
In this particular case Xen must boot with different type of cpus, so the
boot argument hmp_unsafe must be enabled.
Luca Fancellu (7):
tools/cpupools: Give a name to unnamed cpupools
xen/sched: create public function for cpupools creation
xen/sched: retrieve scheduler id by name
xen/cpupool: Create different cpupools at boot time
xen/cpupool: Don't allow removing cpu0 from cpupool0
arm/dom0less: assign dom0less guests to cpupools
xen/cpupool: Allow cpupool0 to use different scheduler
MAINTAINERS| 2 +-
docs/misc/arm/device-tree/booting.txt | 5 +
docs/misc/arm/device-tree/cpupools.txt | 140 +++
tools/helpers/xen-init-dom0.c | 37 +++-
tools/libs/light/libxl_utils.c | 3 +-
xen/arch/arm/domain_build.c| 19 +-
xen/arch/arm/include/asm/smp.h | 3 +
xen/common/Kconfig | 7 +
xen/common/domain.c| 2 +-
xen/common/sched/Makefile | 1 +
xen/common/sched/boot-cpupool.c| 234 +
xen/common/sched/core.c| 40 +++--
xen/common/sched/cpupool.c | 43 -
xen/include/public/domctl.h| 5 +-
xen/include/xen/sched.h| 53 ++
15 files changed, 563 insertions(+), 31 deletions(-)
create mode 100644 docs/misc/arm/device-tree/cpupools.txt
create mode 100644 xen/common/sched/boot-cpupool.c
--
2.17.1
POLL: Would you attend a Xen Summit in Cambridge UK in September?
Hello all, EXECUTIVE SUMMARY The current form of the Xen Summit this year we’re considering is as follows: 1. Two days of “primarily virtual” talks, with a physical add-on for those in the Cambridge UK area, or willing to fly there. This would be relatively low-key, probably hosted on a company premesis; listening to the talks in some conference rooms, with catered food / coffee provided, and pub / meal sessions in the evening. 2. Two days of “primarily physical” discussion sessions, at the same location. To help with location planning, please fill out the following survey: https://cryptpad.fr/form/#/2/form/view/93hTkvOnhFQhmzydZ4fONMTr8AABMPAEEou-SIS1hww/ BACKGROUND We had initially planned to have a “primarily physical summit with a virtual add-on”, similar to the summits we’ve had in the past, in Romania this year. We have decided to do something else this year for a number of reasons: 1. Difficulties in scheduling with the originally intended venue 2. A war going on in the neighboring country 3. One of the important contributor companies (based in Cambridge) unlikely to be able to send anyone outside the country this year. My original idea was to flip from “primarily physical with a virtual add-on” to “primarily virtual with a physical add-on”: have the talks primarily on Big Blue Button as with the last two years, but have some locations where people could watch the talks together in some conference rooms, and have evening pub sessions / meals for those on-site. This would allow people living within driving distance of Cambridge — and anyone willing to come to Cambridge for a few days — to get the face-to-face interaction which is so helpful for a project like ours, while not requiring us to find and pay for a full-blown conference venue. At the last community call, however, it was pointed out that the design sessions are significantly reduced in effectiveness when they aren’t being done in person with a whiteboard. Hence the proposal to make the design sessions primarily physical, and somewhat separate from the virtual part of the summit. It’s still a work in progress; feedback is welcome. But your response regarding the probability that you’ll be able to participate will help us plan. Thanks, -George Dunlap signature.asc Description: Message signed with OpenPGP
Re: [PATCH] x86: make "dom0_nodes=" work with credit2
On Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote: > On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote: > > > > Credit2 moving the vCPU-s off of their initially assigned ones > > right > > away of course renders sched_select_initial_cpu()'s use of > > cpu_cycle() > > pretty useless. > > > Mmm... you mean that Credit2 is moving the vCPUs off they're assigned > ones _right_now_, or that it will, with this patch? > > If you mean the former, I'm not sure it is. In fact, when > sched_select_initial_cpu() is called for dom0, dom0's node affinity > is > just all nodes, isn't it? > Actually, it's what results from dom0_nodes. I was forgetting that we set d->node_affinity while parsing the parameter. That said, I've added some logging, to better understand what is going on, and there are some not obvious (at least, not to me) things that are happening, and it seems that what is causing problems is the call to sched_insert_unit(), within sched_init_vcpu(). I have to leave now, but I will report what I've found ASAP (probably tomorrow, though). Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ --- <> (Raistlin Majere) signature.asc Description: This is a digitally signed message part
[ovmf test] 169308: regressions - FAIL
flight 169308 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169308/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 326 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 15 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD
On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index efb85c6d8e2d5..7e07dd69262a7 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1607,10 +1607,8 @@ static void nvme_config_discard(struct gendisk *disk,
> struct nvme_ns *ns)
> struct request_queue *queue = disk->queue;
> u32 size = queue_logical_block_size(queue);
>
> - if (ctrl->max_discard_sectors == 0) {
> - blk_queue_flag_clear(QUEUE_FLAG_DISCARD, queue);
> + if (ctrl->max_discard_sectors == 0)
> return;
> - }
I think we need to update the queue limit in this condition. While unlikley,
the flag was cleared here in case the device changed support for discard from
the previous reset.
[xen-unstable-smoke test] 169304: tolerable all pass - PUSHED
flight 169304 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169304/ 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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen f44201124e8713f6eff80f349351b5740001c6fc baseline version: xen 8847ec08fd0eecbe3da944fdd49ca3d755e8a9bf Last test of basis 169250 2022-04-08 20:03:24 Z2 days Testing same since 169304 2022-04-11 11:00:27 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Henry Wang Jan Beulich Julien Grall Michal Orzel Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 8847ec08fd..f44201124e f44201124e8713f6eff80f349351b5740001c6fc -> smoke
[ovmf test] 169307: regressions - FAIL
flight 169307 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169307/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 325 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 14 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
[ovmf test] 169306: regressions - FAIL
flight 169306 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169306/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 324 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 13 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD
On 09/04/2022 06:50, Christoph Hellwig wrote: > 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 for it. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Martin K. Petersen > Acked-by: Christoph Böhmwalder [btrfs] > Acked-by: Coly Li [bcache] > --- For > drivers/s390/block/dasd_fba.c | 1 - Acked-by: Jan Höppner
Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
On 11.04.2022 13:00, Julien Grall wrote: > On 11/04/2022 11:45, Jan Beulich wrote: >> On 11.04.2022 12:25, Julien Grall wrote: >>> On 11/04/2022 07:13, Jan Beulich wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v) unsigned int port; struct evtchn *chn; +/* + * The work done below is an attempt to keep pIRQ-s on the pCPU-s that the + * vCPU-s they're to be delivered to run on. In order to limit lock + * contention, check for an empty list prior to acquiring the lock. In the + * worst case a pIRQ just bound to this vCPU will be delivered elsewhere + * until the vCPU is migrated (again) to another pCPU. + */ >>> >>> AFAIU, the downside is another pCPU (and therefore vCPU) will get >>> disturbed by the interrupt. >> >> But only rarely, i.e. in case a race would actually have occurred. > > Maybe I am too paranoid here. The other side of race is controlled by a > domain. So wouldn't it be possible to increase how often the race is hit? Yes, of course - just to harm itself. >>> >>> Are you sure? Wouldn't this also harm the next vCPU running on the pCPU >>> because it will get interrupted more often? >> >> Possibly, sure. But we don't make any promises here. And recall that >> this optimization as a whole has been put under question in the past. > > I don't remember this discussion. Do you have a pointer? I'm sorry, but no, I don't have a pointer. This may even have been on irc. All I recall (or at least I think I do) is that it was Andrew who raised the concern. Jan
Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time
Hi Luca,
On 11/04/2022 12:30, Luca Fancellu wrote:
On 11 Apr 2022, at 11:58, Julien Grall wrote:
Hi Luca,
On 08/04/2022 09:45, Luca Fancellu wrote:
diff --git a/docs/misc/arm/device-tree/cpupools.txt
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c66f
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
+==
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+ACPI is not supported for this feature.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+Must be a list of device tree phandle to nodes describing cpus (e.g. having
+device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+Must be a string having the name of a Xen scheduler. Check the sched=<...>
+boot argument for allowed values [1]. When this property is omitted, the
Xen
+default scheduler will be used.
+
+
+Constraints
+===
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is
assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+The boot cpu must be assigned to Pool-0, so the cpupool containing that core
+will become Pool-0 automatically.
+
+
+Examples
+
+
+A system having two types of core, the following device tree specification will
+instruct Xen to have two cpupools:
+
+- The cpupool with id 0 will have 4 cpus assigned.
+- The cpupool with id 1 will have 2 cpus assigned.
AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it would
be possible that the ID are inverted here.
This could happen if you want to keep the boot CPU in pool 0 and it is not
cpu@0 (some bootloaders allows you to change the boot CPU).
Yes I will specify that the boot cpu is listed in cpupool_a, so that cpupool
will have id 0 regardless of the parsing order.
This only covers the case where are two cpupools.
AFAIK, there are no guarantee that Xen will parse the DT or the compiler
will generate the DT the way you want. So for three cpupools, we still
don't know which pool will be ID 1/2.
See more below.
Also, here you write "The cpupool with id X" but ...
+A system having the cpupools specification below will instruct Xen to have
three
+cpupools:
+
+- The cpupool Pool-0 will have 2 cpus assigned.
+- The cpupool Pool-1 will have 2 cpus assigned.
+- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not
+ assigned cpus a53_3 and a53_4).
here you write "The cpupool Pool-X". Can you be consistent?
Sure, do you have a preference between “The cpupool with id X” and “Pool-X”?
Otherwise I would go for Pool-X everywhere.
Using "cpupool with ID 0" is definitely wrong. Pool-X is marginally
better because an admin may think that this name will match what we have
in Xen.
So I think it would be better to use the node name and mention that
there are no guarantee in which ID will used by Xen.
On a separate topic, I think dom0_max_vcpus() needs to be updated to by default
(i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the number of
vCPUs in the cpupool (I think 0) used to created dom0.
Yes right, I didn’t think about that, I think the change could be something
like that:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9c67a483d4a4..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -73,7 +73,10 @@ custom_param("dom0_mem", parse_dom0_mem);
unsigned int __init dom0_max_vcpus(void)
{
if ( opt_dom0_max_vcpus == 0 )
-opt_dom0_max_vcpus = num_online_cpus();
+{
+ASSERT(cpupool0);
+opt_dom0_max_vcpus = cpumask_weight(cpupool_valid_cpus(cpupool0));
+}
if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
opt_dom0_max_vcpus = MAX_VIRT_CPUS;
And if you agree I will include the changes for the v7.
This should work.
Cheers,
--
Julien Grall
[ovmf test] 169305: regressions - FAIL
flight 169305 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169305/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 323 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 12 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
[linux-linus test] 169294: tolerable FAIL - PUSHED
flight 169294 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/169294/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169286 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169286 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169286 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169286 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169286 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169286 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169286 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169286 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass version targeted for testing: linuxce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e baseline version: linux8b57b3046107b50ebecb65537a172ef3d6cec673 Last test of basis 169286 2022-04-10 21:09:47 Z0 days Testing same since 169294 2022-04-11 03:37:59 Z0 days1 attempts People who touched revisions under test: Linus Torvalds jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-ar
Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time
> On 11 Apr 2022, at 11:58, Julien Grall wrote:
>
> Hi Luca,
>
> On 08/04/2022 09:45, Luca Fancellu wrote:
>> diff --git a/docs/misc/arm/device-tree/cpupools.txt
>> b/docs/misc/arm/device-tree/cpupools.txt
>> new file mode 100644
>> index ..40cc8135c66f
>> --- /dev/null
>> +++ b/docs/misc/arm/device-tree/cpupools.txt
>> @@ -0,0 +1,140 @@
>> +Boot time cpupools
>> +==
>> +
>> +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible
>> to
>> +create cpupools during boot phase by specifying them in the device tree.
>> +ACPI is not supported for this feature.
>> +
>> +Cpupools specification nodes shall be direct childs of /chosen node.
>> +Each cpupool node contains the following properties:
>> +
>> +- compatible (mandatory)
>> +
>> +Must always include the compatiblity string: "xen,cpupool".
>> +
>> +- cpupool-cpus (mandatory)
>> +
>> +Must be a list of device tree phandle to nodes describing cpus (e.g.
>> having
>> +device_type = "cpu"), it can't be empty.
>> +
>> +- cpupool-sched (optional)
>> +
>> +Must be a string having the name of a Xen scheduler. Check the
>> sched=<...>
>> +boot argument for allowed values [1]. When this property is omitted,
>> the Xen
>> +default scheduler will be used.
>> +
>> +
>> +Constraints
>> +===
>> +
>> +If no cpupools are specified, all cpus will be assigned to one cpupool
>> +implicitly created (Pool-0).
>> +
>> +If cpupools node are specified, but not every cpu brought up by Xen is
>> assigned,
>> +all the not assigned cpu will be assigned to an additional cpupool.
>> +
>> +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen
>> will
>> +stop.
>> +
>> +The boot cpu must be assigned to Pool-0, so the cpupool containing that core
>> +will become Pool-0 automatically.
>> +
>> +
>> +Examples
>> +
>> +
>> +A system having two types of core, the following device tree specification
>> will
>> +instruct Xen to have two cpupools:
>> +
>> +- The cpupool with id 0 will have 4 cpus assigned.
>> +- The cpupool with id 1 will have 2 cpus assigned.
>
> AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it
> would be possible that the ID are inverted here.
>
> This could happen if you want to keep the boot CPU in pool 0 and it is not
> cpu@0 (some bootloaders allows you to change the boot CPU).
Hi Julien,
Yes I will specify that the boot cpu is listed in cpupool_a, so that cpupool
will have id 0 regardless of the parsing order.
>
> Also, here you write "The cpupool with id X" but ...
>
>> +A system having the cpupools specification below will instruct Xen to have
>> three
>> +cpupools:
>> +
>> +- The cpupool Pool-0 will have 2 cpus assigned.
>> +- The cpupool Pool-1 will have 2 cpus assigned.
>> +- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the
>> not
>> + assigned cpus a53_3 and a53_4).
>
> here you write "The cpupool Pool-X". Can you be consistent?
Sure, do you have a preference between “The cpupool with id X” and “Pool-X”?
Otherwise I would go for Pool-X everywhere.
>
> On a separate topic, I think dom0_max_vcpus() needs to be updated to by
> default (i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the
> number of vCPUs in the cpupool (I think 0) used to created dom0.
Yes right, I didn’t think about that, I think the change could be something
like that:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9c67a483d4a4..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -73,7 +73,10 @@ custom_param("dom0_mem", parse_dom0_mem);
unsigned int __init dom0_max_vcpus(void)
{
if ( opt_dom0_max_vcpus == 0 )
-opt_dom0_max_vcpus = num_online_cpus();
+{
+ASSERT(cpupool0);
+opt_dom0_max_vcpus = cpumask_weight(cpupool_valid_cpus(cpupool0));
+}
if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
opt_dom0_max_vcpus = MAX_VIRT_CPUS;
And if you agree I will include the changes for the v7.
Cheers,
Luca
>
> Cheers,
>
> --
> Julien Grall
Re: [PATCH V4 2/2] xen/arm: Add i.MX lpuart early printk support
Hi Julien, On 11.04.2022 12:23, Julien Grall wrote: > Hi, > > On 11/04/2022 07:24, Michal Orzel wrote: >> On 08.04.2022 16:09, Peng Fan (OSS) wrote: >>> From: Peng Fan >>> >>> Signed-off-by: Peng Fan >>> --- >>> xen/arch/arm/Kconfig.debug | 14 +++ >>> xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 + >>> 2 files changed, 66 insertions(+) >>> create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc >>> >>> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug >>> index 35ccd13273..842d768280 100644 >>> --- a/xen/arch/arm/Kconfig.debug >>> +++ b/xen/arch/arm/Kconfig.debug >>> @@ -58,6 +58,16 @@ choice >>> This option is preferred over the platform specific >>> options; the platform specific options are deprecated >>> and will soon be removed. >>> + config EARLY_UART_CHOICE_IMX_LPUART >>> + select EARLY_UART_IMX_LPUART >>> + depends on ARM_64 >>> + bool "Early printk via i.MX LPUART" >>> + help >>> + Say Y here if you wish the early printk to direct their >>> + output to a i.MX LPUART. You can use this option to >>> + provide the parameters for the i.MX LPUART rather than >>> + selecting one of the platform specific options below if >>> + you know the parameters for the port. >>> config EARLY_UART_CHOICE_MESON >>> select EARLY_UART_MESON >>> depends on ARM_64 >>> @@ -186,6 +196,9 @@ config EARLY_UART_CADENCE >>> config EARLY_UART_EXYNOS4210 >>> select EARLY_PRINTK >>> bool >>> +config EARLY_UART_IMX_LPUART >>> + select EARLY_PRINTK >>> + bool >>> config EARLY_UART_MESON >>> select EARLY_PRINTK >>> bool >>> @@ -283,6 +296,7 @@ config EARLY_PRINTK_INC >>> default "debug-8250.inc" if EARLY_UART_8250 >>> default "debug-cadence.inc" if EARLY_UART_CADENCE >>> default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210 >>> + default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART >>> default "debug-meson.inc" if EARLY_UART_MESON >>> default "debug-mvebu.inc" if EARLY_UART_MVEBU >>> default "debug-pl011.inc" if EARLY_UART_PL011 >>> diff --git a/xen/arch/arm/arm64/debug-imx-lpuart.inc >>> b/xen/arch/arm/arm64/debug-imx-lpuart.inc >>> new file mode 100644 >>> index 00..f68252da86 >>> --- /dev/null >>> +++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc >>> @@ -0,0 +1,52 @@ >>> +/* >>> + * xen/arch/arm/arm64/debug-imx-lpuart.inc >>> + * >>> + * i.MX8QM specific debug code >>> + * >>> + * Peng Fan >>> + * Copyright 2022 NXP >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +#include >>> + >>> +.macro early_uart_init wb wc wd >>> +/* Already initialized in bootloader */ >>> +.endm >>> + >> FWICS, early_uart_init call is protected with CONFIG_EARLY_UART_INIT that is >> set >> only for PL011 UART. So I think there is no need to implement this empty >> macro, >> unless we want to keep the same macros across the files no matter whether in >> use or not. >> I think you need to ask Julien. > > The call to early_uart_init is indeed protected by #ifdef > CONFIG_EARLY_UART_INIT. The goal was to avoid having all debug-*.inc to > implement dummy helper. > > So I would prefer if early_uart_init is not implemented for > debug-imx-lpuart.inc. > > Cheers, > I agree. As a side note, do we still need to support platform specific options for early printk? If not, I am happy to send a patch removing them. Cheers, Michal
Re: Xen Project management working group
https://doodle.com/meeting/participate/id/b822G1ge I will probably leave the Doodle opened for few days (like up to Monday evening) until we can decide the best schedule without waiting too long. When I'll have the validated time slot, I'll communicate about it here. So, as planned, here is the selected date. I picked this Thursday, April the 14th, at 4PM UTC (5PM London time, 6PM Paris time). Don't forget to add this to your calendar :) Meeting place will be: https://meet.vates.fr/xenmgmt See you soon! Regards, Olivier Lambert | Vates CEO XCP-ng & Xen Orchestra - Vates solutions w: vates.fr | xcp-ng.org | xen-orchestra.com
Re: [PATCH V4 1/2] xen/arm: Add i.MX lpuart driver
Hi Julien, On 11.04.2022 12:20, Julien Grall wrote: > Hi, > > On 11/04/2022 07:26, Michal Orzel wrote: >> On 08.04.2022 16:09, Peng Fan (OSS) wrote: >>> From: Peng Fan >>> >>> The i.MX LPUART Documentation: >>> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC >>> Chatper 13.6 Low Power Universal Asynchronous Receiver/ >>> Transmitter (LPUART) >>> >>> Tested-by: Henry Wang >>> Signed-off-by: Peng Fan >>> --- >>> xen/arch/arm/include/asm/imx-lpuart.h | 64 ++ >>> xen/drivers/char/Kconfig | 7 + >>> xen/drivers/char/Makefile | 1 + >>> xen/drivers/char/imx-lpuart.c | 276 ++ >>> 4 files changed, 348 insertions(+) >>> create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h >>> create mode 100644 xen/drivers/char/imx-lpuart.c >>> >>> diff --git a/xen/arch/arm/include/asm/imx-lpuart.h >>> b/xen/arch/arm/include/asm/imx-lpuart.h >>> new file mode 100644 >>> index 00..26e2cf0249 >>> --- /dev/null >>> +++ b/xen/arch/arm/include/asm/imx-lpuart.h >>> @@ -0,0 +1,64 @@ >>> +/* >>> + * xen/arch/arm/include/asm/imx-lpuart.h >>> + * >>> + * Common constant definition between early printk and the LPUART driver >>> + * >>> + * Peng Fan >>> + * Copyright 2022 NXP >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + */ >>> + >>> +#ifndef __ASM_ARM_IMX_LPUART_H__ >>> +#define __ASM_ARM_IMX_LPUART_H__ >>> + >>> +/* 32-bit register definition */ >>> +#define UARTBAUD (0x10) >>> +#define UARTSTAT (0x14) >>> +#define UARTCTRL (0x18) >>> +#define UARTDATA (0x1C) >>> +#define UARTMATCH (0x20) >>> +#define UARTMODIR (0x24) >>> +#define UARTFIFO (0x28) >>> +#define UARTWATER (0x2c) >>> + >>> +#define UARTSTAT_TDRE BIT(23, UL) >>> +#define UARTSTAT_TC BIT(22, UL) >>> +#define UARTSTAT_RDRF BIT(21, UL) >>> +#define UARTSTAT_OR BIT(19, UL) >>> + >>> +#define UARTBAUD_OSR_SHIFT (24) >>> +#define UARTBAUD_OSR_MASK (0x1f) >>> +#define UARTBAUD_SBR_MASK (0x1fff) >>> +#define UARTBAUD_BOTHEDGE (0x0002) >>> +#define UARTBAUD_TDMAE (0x0080) >>> +#define UARTBAUD_RDMAE (0x0020)It seems like you missed my comment >>> about alignment from the previous patch version. >> Please keep the same alignment of values within the same section. > > I haven't yet reviewed this patch. But if this is the only comment, then I > can update the alignment on commit. > > Cheers, > All my other findings have already been fixed by Peng. This is the last one as it was forgotten. Patch 2/2 still has sth to be fixed so the alignment can be fixed in the same shot as well. Cheers, Michal
Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
Hi, On 11/04/2022 11:45, Jan Beulich wrote: On 11.04.2022 12:25, Julien Grall wrote: On 11/04/2022 07:13, Jan Beulich wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v) unsigned int port; struct evtchn *chn; +/* + * The work done below is an attempt to keep pIRQ-s on the pCPU-s that the + * vCPU-s they're to be delivered to run on. In order to limit lock + * contention, check for an empty list prior to acquiring the lock. In the + * worst case a pIRQ just bound to this vCPU will be delivered elsewhere + * until the vCPU is migrated (again) to another pCPU. + */ AFAIU, the downside is another pCPU (and therefore vCPU) will get disturbed by the interrupt. But only rarely, i.e. in case a race would actually have occurred. Maybe I am too paranoid here. The other side of race is controlled by a domain. So wouldn't it be possible to increase how often the race is hit? Yes, of course - just to harm itself. Are you sure? Wouldn't this also harm the next vCPU running on the pCPU because it will get interrupted more often? Possibly, sure. But we don't make any promises here. And recall that this optimization as a whole has been put under question in the past. I don't remember this discussion. Do you have a pointer? If we'd drop it, we'd also impact various vCPU-s in not really predictable ways. Cheers, -- Julien Grall
Re: [xen-4.12-testing test] 169199: regressions - FAIL
Hi, On 08/04/2022 16:26, Roger Pau Monné wrote: On Fri, Apr 08, 2022 at 12:24:27PM +0100, Julien Grall wrote: Hi Roger, On 08/04/2022 12:16, Roger Pau Monné wrote: On Fri, Apr 08, 2022 at 12:08:02PM +0100, Julien Grall wrote: Hi, On 08/04/2022 12:01, Roger Pau Monné wrote: I could add a suitable dom0_max_vcpus parameter to osstest. XenServer uses 16 for example. I'm afraid a fixed number won't do, the more that iirc there are systems with just a few cores in the pool (and you don't want to over-commit by default). But this won't over commit, it would just assign dom0 16 vCPUs at most, if the system has less than 16 vCPUs that's what would be assigned to dom0. AFAICT, this is not the case on Arm. If you ask 16 vCPUs, then you will get that number even if there are 8 pCPUs. In fact, the documentation of dom0_max_vcpus suggests that the numbers of vCPUs can be more than the number of pCPUs. It was my understanding that you could only achieve that by using the min-max nomenclature, so in order to force 16 vCPUs always you would have to use: dom0_max_vcpus=16-16 Otherwise the usage of '_max_' in the option name is pointless, and it should instead be dom0_vcpus. Anyway, I could use: dom0_max_vcpus=1-16 Which is unambiguous and should get us 1 vCPU at least, or 16vCPUs at most. Unfortunately, Arm doesn't support the min-max nomenclature. Hm, can we update the command line document then? There's no mention that the min-max nomenclature is only available to x86. I assume it's not possible to share the logic here so that both Arm and x86 parse the option in the same way? Looking at the x86 implementation, I think we can re-use everything but the pv_shim and NUMA bits. We don't need to store this information anywhere I think. Since we first install plain Debian and then install Xen we can always fetch the number of physical CPUs when running plain Linux and use that to calculate the amount to give to dom0? You will need to check how that works with U-boot. I can't remember whether the script is loaded via tftp or stored on the local disk. Cheers, -- Julien Grall
Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time
Hi Luca, On 08/04/2022 09:45, Luca Fancellu wrote: diff --git a/docs/misc/arm/device-tree/cpupools.txt b/docs/misc/arm/device-tree/cpupools.txt new file mode 100644 index ..40cc8135c66f --- /dev/null +++ b/docs/misc/arm/device-tree/cpupools.txt @@ -0,0 +1,140 @@ +Boot time cpupools +== + +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to +create cpupools during boot phase by specifying them in the device tree. +ACPI is not supported for this feature. + +Cpupools specification nodes shall be direct childs of /chosen node. +Each cpupool node contains the following properties: + +- compatible (mandatory) + +Must always include the compatiblity string: "xen,cpupool". + +- cpupool-cpus (mandatory) + +Must be a list of device tree phandle to nodes describing cpus (e.g. having +device_type = "cpu"), it can't be empty. + +- cpupool-sched (optional) + +Must be a string having the name of a Xen scheduler. Check the sched=<...> +boot argument for allowed values [1]. When this property is omitted, the Xen +default scheduler will be used. + + +Constraints +=== + +If no cpupools are specified, all cpus will be assigned to one cpupool +implicitly created (Pool-0). + +If cpupools node are specified, but not every cpu brought up by Xen is assigned, +all the not assigned cpu will be assigned to an additional cpupool. + +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will +stop. + +The boot cpu must be assigned to Pool-0, so the cpupool containing that core +will become Pool-0 automatically. + + +Examples + + +A system having two types of core, the following device tree specification will +instruct Xen to have two cpupools: + +- The cpupool with id 0 will have 4 cpus assigned. +- The cpupool with id 1 will have 2 cpus assigned. AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it would be possible that the ID are inverted here. This could happen if you want to keep the boot CPU in pool 0 and it is not cpu@0 (some bootloaders allows you to change the boot CPU). Also, here you write "The cpupool with id X" but ... +A system having the cpupools specification below will instruct Xen to have three +cpupools: + +- The cpupool Pool-0 will have 2 cpus assigned. +- The cpupool Pool-1 will have 2 cpus assigned. +- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not + assigned cpus a53_3 and a53_4). here you write "The cpupool Pool-X". Can you be consistent? On a separate topic, I think dom0_max_vcpus() needs to be updated to by default (i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the number of vCPUs in the cpupool (I think 0) used to created dom0. Cheers, -- Julien Grall
[ovmf test] 169302: regressions - FAIL
flight 169302 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169302/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 42 days Failing since168258 2022-03-01 01:55:31 Z 41 days 322 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 11 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
On 11.04.2022 12:25, Julien Grall wrote: > On 11/04/2022 07:13, Jan Beulich wrote: >> --- a/xen/common/event_channel.c >> +++ b/xen/common/event_channel.c >> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v) >> unsigned int port; >> struct evtchn *chn; >> >> +/* >> + * The work done below is an attempt to keep pIRQ-s on the pCPU-s >> that the >> + * vCPU-s they're to be delivered to run on. In order to limit lock >> + * contention, check for an empty list prior to acquiring the lock. >> In the >> + * worst case a pIRQ just bound to this vCPU will be delivered >> elsewhere >> + * until the vCPU is migrated (again) to another pCPU. >> + */ > > AFAIU, the downside is another pCPU (and therefore vCPU) will get > disturbed by the interrupt. But only rarely, i.e. in case a race would actually have occurred. >>> >>> Maybe I am too paranoid here. The other side of race is controlled by a >>> domain. So wouldn't it be possible to increase how often the race is hit? >> >> Yes, of course - just to harm itself. > > Are you sure? Wouldn't this also harm the next vCPU running on the pCPU > because it will get interrupted more often? Possibly, sure. But we don't make any promises here. And recall that this optimization as a whole has been put under question in the past. If we'd drop it, we'd also impact various vCPU-s in not really predictable ways. Jan
Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..
Hi Stefano,
> On 9 Apr 2022, at 02:44, Stefano Stabellini wrote:
>
> On Fri, 8 Apr 2022, Stefano Stabellini wrote:
>> On Wed, 23 Mar 2022, Rahul Singh wrote:
>>> in dom0less system. This patch introduce the new feature to support the
>>> signaling between two domUs in dom0less system.
>>>
>>> Signed-off-by: Rahul Singh
>>> ---
>>> docs/designs/dom0less-evtchn.md | 96 +
>>> 1 file changed, 96 insertions(+)
>>> create mode 100644 docs/designs/dom0less-evtchn.md
>>>
>>> diff --git a/docs/designs/dom0less-evtchn.md
>>> b/docs/designs/dom0less-evtchn.md
>>> new file mode 100644
>>> index 00..6a1b7e8c22
>>> --- /dev/null
>>> +++ b/docs/designs/dom0less-evtchn.md
>>> @@ -0,0 +1,96 @@
>>> +# Signaling support between two domUs on dom0less system
>>> +
>>> +## Current state: Draft version
>>> +
>>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>>> +
>>> +## Problem Statement:
>>> +
>>> +The goal of this work is to define a simple signaling system between Xen
>>> guests
>>> +in dom0less systems.
>>> +
>>> +In dom0less system, we cannot make use of xenbus and xenstore that are
>>> used in
>>> +normal systems with dynamic VMs to communicate between domains by
>>> providing a
>>> +bus abstraction for paravirtualized drivers.
>>> +
>>> +One possible solution to implement the signaling system between domUs is
>>> based
>>> +on event channels.
>>
>> I suggest to reword this as follows:
>>
>> ---
>> Dom0less guests would benefit from a statically-defined memory sharing
>> and signally system for communication. One that would be immediately
>> available at boot without any need for dynamic configurations.
>>
>> In embedded a great variety of guest operating system kernels exist,
>> many of which don't have support for xenstore, grant table or other
>> complex drivers. Some of them are small kernel-space applications (often
>> called "baremetal", not to be confused with the term "baremetal" used in
>> datacenter which means "without hypervisors") or RTOSes. Additionally,
>> for safety reasons, users often need to be able to configure the full
>> system statically so that it can be verified statically.
>>
>> Event channels are very simple and can be added even to baremetal
>> applications. This proposal introduces a way to define them statically
>> to make them suitable to dom0less embedded deployments.
>> ---
>>
>>
>>> +## Proposal:
>>> +
>>> +Event channels are the basic primitive provided by Xen for event
>>> notifications.
>>> +An event channel is a logical connection between 2 domains (more
>>> specifically
>>> +between dom1,port1 and dom2,port2). They essentially store one bit of
>>> +information, the event of interest is signalled by transitioning this bit
>>> from
>>> +0 to 1. An event is an equivalent of a hardware interrupt.
>>> +
>>> +Notifications are received by a guest via an interrupt from Xen to the
>>> guest,
>>> +indicating when an event arrives (setting the bit). Further notifications
>>> are
>>> +masked until the bit is cleared again. When a domain wants to wait for
>>> data it
>>> +will block until an event arrives, and then send an event to signal that
>>> data
>>> +has been consumed. Events are delivered asynchronously to guests and are
>>> +enqueued when the guest is not running.
>>> +
>>> +Event channel communication will be established statically between two domU
>>> +guests before unpausing the domains after domain creation. Event channel
>>> +connection information between domUs will be passed to XEN via device tree
>>> +node.
>>> +
>>> +Under the /chosen node, there needs to be sub nodes with compatible
>>> +"xen,evtchn" that descibes the event channel connection between two domUs.
>>> +
>>> +The event channel sub-node has the following properties:
>>> +
>>> +- compatible
>>> +
>>> +"xen,evtchn"
>>> +
>>> +- xen,evtchn
>>> +
>>> +The property is four numbers of tuples of
>>> +(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
>>> +
>>> +local-port-domU1 is an integer value that will be used to allocte local
>>> +port for domU1 to send an event notification to the remote domain.
>>> +
>>> +domU1-phandle is a single phandle to an domain to which
>>> local-port-domU1
>>> +will be allocated.
>>> +
>>> +local-port-domU2 is an integer value that will be used to allocte local
>>> +port for domU2 to send an event notification to the remote domain.
>>> +
>>> +domU2-phandle is a single phandle to an domain to which
>>> local-port-domU2
>>> +will be allocated.
>>> +
>>> +Example:
>>> +
>>> +chosen {
>>> +
>>> +
>>> +domU1: domU1 {
>>> +..
>>> +};
>>> +
>>> +domU2: domU2 {
>>> +..
>>> +};
>>> +
>>> +evtchn@1 {
>>> +compatible = "xen,evtchn";
>>> +xen,evtchn = <0xa &domU1 0xb &domU2>;
>>> +};
>>> +
>>> +evtchn@2 {
>>> +compatible = "xen,evtchn
Re: [PATCH v4] IOMMU/x86: disallow device assignment to PoD guests
On 11.04.2022 12:29, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
>> While it is okay for IOMMU page tables to be set up for guests starting
>> in PoD mode, actual device assignment may only occur once all PoD
>> entries have been removed from the P2M. So far this was enforced only
>> for boot-time assignment, and only in the tool stack.
>>
>> Also use the new function to replace p2m_pod_entry_count(): Its unlocked
>> access to p2m->pod.entry_count wasn't really okay (irrespective of the
>> result being stale by the time the caller gets to see it). Nor was the
>> use of that function in line with the immediately preceding comment: A
>> PoD guest isn't just one with a non-zero entry count, but also one with
>> a non-empty cache (e.g. prior to actually launching the guest).
>>
>> To allow the tool stack to see a consistent snapshot of PoD state, move
>> the tail of XENMEM_{get,set}_pod_target handling into a function, adding
>> proper locking there.
>>
>> In libxl take the liberty to use the new local variable r also for a
>> pre-existing call into libxc.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Roger Pau Monné
Thanks.
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -20,6 +20,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
>>
>> ASSERT( pod_target >= p2m->pod.count );
>>
>> -ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
>> +if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
>> +ret = -ENOTEMPTY;
>
> ENOTEMPTY seems weird here. I think the reasoning is that the set of
> passthrough devices is not empty?
Yes.
> IMO it's confusing as the function
> itself is related to buffer management, so returning ENOTEMPTY could
> be confused with some other condition.
>
> Might be less ambiguous to use EXDEV.
I don't think there's any particularly good error code to use here.
Hence I've tried to pick one that makes some sense, and which isn't
widely used (this latter aspect would be EXDEV slightly less desirable).
Jan
Re: [PATCH v5 0/2] xen: Linker scripts synchronization
Hi Michal, On 11/04/2022 08:02, Michal Orzel wrote: This patch series aims to do the first step towards linker scripts synchronization. Linker scripts for arm and x86 share a lot of common sections and in order to make the process of changing/improving/syncing them, these sections shall be defined in just one place. The first patch creates an empty header file xen.lds.h to store the constructs mutual to both x86 and arm linker scripts. It also includes this header in the scripts. The second patch populates xen.lds.h with the first portion of common macros and replaces the original contructs with these helpers. Michal Orzel (2): xen: Introduce a header to store common linker scripts content xen: Populate xen.lds.h and make use of its macros I have committed the two patches. Cheers, -- Julien Grall
[libvirt test] 169296: regressions - FAIL
flight 169296 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169296/ 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-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt c11fb2132f313b9aa25ad7c57becc72923623874 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 640 days Failing since151818 2020-07-11 04:18:52 Z 639 days 621 attempts Testing same since 169254 2022-04-09 04:20:15 Z2 days3 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Praveen K Paladugu Richard W.M. Jones Ricky Tigg Robin Lee Rohit Kumar Roman Bogorodskiy
RE: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes
Hi Jan, > -Original Message- > From: Jan Beulich > > Since you also mentioned the changelog entry, I will take a note of this > > series and we can have a discussion about adding it when we do the > > next Xen release (4.17). Would that sound ok with you? > > "Adding it" where? Maybe you mean to the release notes, but that's not > entirely clear. Yeah, I meant the release notes. Thanks for pointing out that I did not use accurate wording. Kind regards, Henry > > Jan
Re: [PATCH v4] IOMMU/x86: disallow device assignment to PoD guests
On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
> While it is okay for IOMMU page tables to be set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time assignment, and only in the tool stack.
>
> Also use the new function to replace p2m_pod_entry_count(): Its unlocked
> access to p2m->pod.entry_count wasn't really okay (irrespective of the
> result being stale by the time the caller gets to see it). Nor was the
> use of that function in line with the immediately preceding comment: A
> PoD guest isn't just one with a non-zero entry count, but also one with
> a non-empty cache (e.g. prior to actually launching the guest).
>
> To allow the tool stack to see a consistent snapshot of PoD state, move
> the tail of XENMEM_{get,set}_pod_target handling into a function, adding
> proper locking there.
>
> In libxl take the liberty to use the new local variable r also for a
> pre-existing call into libxc.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Just one comment below.
> ---
> If p2m->pod.entry_count == p2m->pod.count it is in principle possible to
> permit device assignment by actively resolving all remaining PoD entries.
>
> Initially I thought this was introduced by f89f555827a6 ("remove late
> (on-demand) construction of IOMMU page tables"), but without
> arch_iommu_use_permitted() checking for PoD I think the issue has been
> there before that.
> ---
> v4: Drop tool stack side change (superseded by 07449ecfa425). Extend VM
> event related paragraph of description.
> v3: In p2m_pod_set_mem_target() move check down.
> v2: New.
>
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -20,6 +20,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
>
> ASSERT( pod_target >= p2m->pod.count );
>
> -ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
> +if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
> +ret = -ENOTEMPTY;
ENOTEMPTY seems weird here. I think the reasoning is that the set of
passthrough devices is not empty? IMO it's confusing as the function
itself is related to buffer management, so returning ENOTEMPTY could
be confused with some other condition.
Might be less ambiguous to use EXDEV.
Thanks, Roger.
Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time
On Mon, 2022-04-11 at 08:29 +, Luca Fancellu wrote: > > On 11 Apr 2022, at 07:15, Jan Beulich wrote: > > On 08.04.2022 22:25, Stefano Stabellini wrote: > > > In my opinion it is best if the maintenance of boot_cpupools.c > > > falls > > > under "CPU POOLS". Luca, you can retain my reviewed-by when you > > > add > > > the change to MAINTAINERS or rename the file. > > > > Yet even then, with cpupools.c living in sched/, ... > > > > > I don't have an opinion if it should be called > > > xen/common/boot_cpupools.c or xen/common/boot-cpupools.c > > > > > > > ... this one may want living there are well. > > Yes I agree with you all, I will rename it to xen/common/sched/boot- > cpupool.c > and add it in MAINTAINERS. > FWIW, I agree as well. With something like this, IMO: CPU POOLS M: Juergen Gross M: Dario Faggioli S: Supported F: xen/common/sched/*cpupool.c Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ --- <> (Raistlin Majere) signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()
Hi, On 11/04/2022 07:13, Jan Beulich wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v) unsigned int port; struct evtchn *chn; +/* + * The work done below is an attempt to keep pIRQ-s on the pCPU-s that the + * vCPU-s they're to be delivered to run on. In order to limit lock + * contention, check for an empty list prior to acquiring the lock. In the + * worst case a pIRQ just bound to this vCPU will be delivered elsewhere + * until the vCPU is migrated (again) to another pCPU. + */ AFAIU, the downside is another pCPU (and therefore vCPU) will get disturbed by the interrupt. But only rarely, i.e. in case a race would actually have occurred. Maybe I am too paranoid here. The other side of race is controlled by a domain. So wouldn't it be possible to increase how often the race is hit? Yes, of course - just to harm itself. Are you sure? Wouldn't this also harm the next vCPU running on the pCPU because it will get interrupted more often? Cheers, -- Julien Grall
Re: [PATCH V4 2/2] xen/arm: Add i.MX lpuart early printk support
Hi, On 11/04/2022 07:24, Michal Orzel wrote: On 08.04.2022 16:09, Peng Fan (OSS) wrote: From: Peng Fan Signed-off-by: Peng Fan --- xen/arch/arm/Kconfig.debug | 14 +++ xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 + 2 files changed, 66 insertions(+) create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug index 35ccd13273..842d768280 100644 --- a/xen/arch/arm/Kconfig.debug +++ b/xen/arch/arm/Kconfig.debug @@ -58,6 +58,16 @@ choice This option is preferred over the platform specific options; the platform specific options are deprecated and will soon be removed. + config EARLY_UART_CHOICE_IMX_LPUART + select EARLY_UART_IMX_LPUART + depends on ARM_64 + bool "Early printk via i.MX LPUART" + help + Say Y here if you wish the early printk to direct their + output to a i.MX LPUART. You can use this option to + provide the parameters for the i.MX LPUART rather than + selecting one of the platform specific options below if + you know the parameters for the port. config EARLY_UART_CHOICE_MESON select EARLY_UART_MESON depends on ARM_64 @@ -186,6 +196,9 @@ config EARLY_UART_CADENCE config EARLY_UART_EXYNOS4210 select EARLY_PRINTK bool +config EARLY_UART_IMX_LPUART + select EARLY_PRINTK + bool config EARLY_UART_MESON select EARLY_PRINTK bool @@ -283,6 +296,7 @@ config EARLY_PRINTK_INC default "debug-8250.inc" if EARLY_UART_8250 default "debug-cadence.inc" if EARLY_UART_CADENCE default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210 + default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART default "debug-meson.inc" if EARLY_UART_MESON default "debug-mvebu.inc" if EARLY_UART_MVEBU default "debug-pl011.inc" if EARLY_UART_PL011 diff --git a/xen/arch/arm/arm64/debug-imx-lpuart.inc b/xen/arch/arm/arm64/debug-imx-lpuart.inc new file mode 100644 index 00..f68252da86 --- /dev/null +++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc @@ -0,0 +1,52 @@ +/* + * xen/arch/arm/arm64/debug-imx-lpuart.inc + * + * i.MX8QM specific debug code + * + * Peng Fan + * Copyright 2022 NXP + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +.macro early_uart_init wb wc wd +/* Already initialized in bootloader */ +.endm + FWICS, early_uart_init call is protected with CONFIG_EARLY_UART_INIT that is set only for PL011 UART. So I think there is no need to implement this empty macro, unless we want to keep the same macros across the files no matter whether in use or not. I think you need to ask Julien. The call to early_uart_init is indeed protected by #ifdef CONFIG_EARLY_UART_INIT. The goal was to avoid having all debug-*.inc to implement dummy helper. So I would prefer if early_uart_init is not implemented for debug-imx-lpuart.inc. Cheers, -- Julien Grall
Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools
On 11.04.2022 12:20, Luca Fancellu wrote:
>
>
>> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>>
>> On 11.04.2022 10:54, Luca Fancellu wrote:
On 8 Apr 2022, at 13:10, Jan Beulich wrote:
On 08.04.2022 13:15, Luca Fancellu wrote:
>> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
>> On 08.04.2022 11:39, Luca Fancellu wrote:
On 8 Apr 2022, at 10:10, Jan Beulich wrote:
On 08.04.2022 10:45, Luca Fancellu wrote:
> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
> /* Per-vCPU buffer size in bytes. 0 to disable. */
> uint32_t vmtrace_size;
>
> + uint32_t cpupool_id;
This could do with a comment explaining default behavior. In particular
I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
would be impossible to delete pool 0 (but there may of course be
reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
Yet if pool 0 can be removed, zero being passed in here should imo not
lead to failure of VM creation. Otoh I understand that this would
already happen ahead of your change, preventing of which would
apparently possible only via passing CPUPOOLID_NONE here.
>>>
>>> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is
>>> modifying
>>> cpupool_id only for DomUs).
>>
>> But we're talking about dom0less as per the subject of the patch here.
>
> Domains started using dom0less feature are not privileged and can’t do
> any operation
> on cpu pools, that’s why I thought about Dom0.
It's all a matter of XSM policy what a domain may or may not be able
to carry out.
>>>
>>> Yes you are right, however I didn’t see so far this use case with a domU
>>> and the tool stack,
>>> probably because it would need also xenstore etc… I’m aware that there is
>>> some work going
>>> on to enable it also for dom0less domUs, so my question is:
>>>
>>> Do you see this as a blocker for this patch? Are you ok if I send this
>>> patch with just the comment
>>> below or in your opinion this patch requires some other work?
>>
>> Agreement looks to be that there should be precautionary code added
>> to prevent the deleting of pool 0. This imo wants to be a prereq
>> change to the one here.
>
> Since we have the requirement of having cpu0 in pool-0, I’m thinking about a
> check to don’t allow
> Cpu0 to be removed from pool-0, that will cover also the destroy case because
> we can’t destroy
> a cpupool that is not empty.
>
> In your opinion is it ok to proceed with a separate patch as prereq work
> having this change?
Well, I did already say so (see context above).
Jan
Re: [PATCH V4 1/2] xen/arm: Add i.MX lpuart driver
Hi, On 11/04/2022 07:26, Michal Orzel wrote: On 08.04.2022 16:09, Peng Fan (OSS) wrote: From: Peng Fan The i.MX LPUART Documentation: https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC Chatper 13.6 Low Power Universal Asynchronous Receiver/ Transmitter (LPUART) Tested-by: Henry Wang Signed-off-by: Peng Fan --- xen/arch/arm/include/asm/imx-lpuart.h | 64 ++ xen/drivers/char/Kconfig | 7 + xen/drivers/char/Makefile | 1 + xen/drivers/char/imx-lpuart.c | 276 ++ 4 files changed, 348 insertions(+) create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h create mode 100644 xen/drivers/char/imx-lpuart.c diff --git a/xen/arch/arm/include/asm/imx-lpuart.h b/xen/arch/arm/include/asm/imx-lpuart.h new file mode 100644 index 00..26e2cf0249 --- /dev/null +++ b/xen/arch/arm/include/asm/imx-lpuart.h @@ -0,0 +1,64 @@ +/* + * xen/arch/arm/include/asm/imx-lpuart.h + * + * Common constant definition between early printk and the LPUART driver + * + * Peng Fan + * Copyright 2022 NXP + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ASM_ARM_IMX_LPUART_H__ +#define __ASM_ARM_IMX_LPUART_H__ + +/* 32-bit register definition */ +#define UARTBAUD (0x10) +#define UARTSTAT (0x14) +#define UARTCTRL (0x18) +#define UARTDATA (0x1C) +#define UARTMATCH (0x20) +#define UARTMODIR (0x24) +#define UARTFIFO (0x28) +#define UARTWATER (0x2c) + +#define UARTSTAT_TDRE BIT(23, UL) +#define UARTSTAT_TC BIT(22, UL) +#define UARTSTAT_RDRF BIT(21, UL) +#define UARTSTAT_OR BIT(19, UL) + +#define UARTBAUD_OSR_SHIFT (24) +#define UARTBAUD_OSR_MASK (0x1f) +#define UARTBAUD_SBR_MASK (0x1fff) +#define UARTBAUD_BOTHEDGE (0x0002) +#define UARTBAUD_TDMAE(0x0080) +#define UARTBAUD_RDMAE(0x0020)It seems like you missed my comment about alignment from the previous patch version. Please keep the same alignment of values within the same section. I haven't yet reviewed this patch. But if this is the only comment, then I can update the alignment on commit. Cheers, -- Julien Grall
Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools
> On 11 Apr 2022, at 10:08, Jan Beulich wrote:
>
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
> On 8 Apr 2022, at 11:24, Jan Beulich wrote:
> On 08.04.2022 11:39, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 10:10, Jan Beulich wrote:
>>> On 08.04.2022 10:45, Luca Fancellu wrote:
@@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
/* Per-vCPU buffer size in bytes. 0 to disable. */
uint32_t vmtrace_size;
+ uint32_t cpupool_id;
>>>
>>> This could do with a comment explaining default behavior. In particular
>>> I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
>>> would be impossible to delete pool 0 (but there may of course be
>>> reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
>>> Yet if pool 0 can be removed, zero being passed in here should imo not
>>> lead to failure of VM creation. Otoh I understand that this would
>>> already happen ahead of your change, preventing of which would
>>> apparently possible only via passing CPUPOOLID_NONE here.
>>
>> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is
>> modifying
>> cpupool_id only for DomUs).
>
> But we're talking about dom0less as per the subject of the patch here.
Domains started using dom0less feature are not privileged and can’t do any
operation
on cpu pools, that’s why I thought about Dom0.
>>>
>>> It's all a matter of XSM policy what a domain may or may not be able
>>> to carry out.
>>
>> Yes you are right, however I didn’t see so far this use case with a domU and
>> the tool stack,
>> probably because it would need also xenstore etc… I’m aware that there is
>> some work going
>> on to enable it also for dom0less domUs, so my question is:
>>
>> Do you see this as a blocker for this patch? Are you ok if I send this patch
>> with just the comment
>> below or in your opinion this patch requires some other work?
>
> Agreement looks to be that there should be precautionary code added
> to prevent the deleting of pool 0. This imo wants to be a prereq
> change to the one here.
Since we have the requirement of having cpu0 in pool-0, I’m thinking about a
check to don’t allow
Cpu0 to be removed from pool-0, that will cover also the destroy case because
we can’t destroy
a cpupool that is not empty.
In your opinion is it ok to proceed with a separate patch as prereq work having
this change?
>
> Jan
Re: [PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks
On 11.04.2022 12:01, Andrew Cooper wrote: > On 11/04/2022 10:35, Jan Beulich wrote: >> Prior extension of these functions to enable per-device quarantine page >> tables already didn't add more locking there, but merely left in place >> what had been there before. But really locking is unnecessary here: >> We're running with pcidevs_lock held (i.e. multiple invocations of the >> same function [or their teardown equivalents] are impossible, and hence >> there are no "local" races), while all consuming of the data being >> populated here can't race anyway due to happening sequentially >> afterwards. See also the comment in struct arch_pci_dev. >> >> Signed-off-by: Jan Beulich > > It is only legitimate to drop these calls if you delete the mapping_lock > entirely. Otherwise you're breaking the semantics of mapping_lock. Not for all domains other than DomIO. And DomIO is, well, special. As is at what times quarantine_init() is actually being invoked. > Your argument of "well this is already guarded by the pci lock" means > that these are uncontended lock/unlock operations, and therefore not > interesting to drop in the first place. > > This patch is specifically setting us up for an XSA in the future when > the behaviour of the the PCI lock changes, the fix for which will be > revert this patch. That wouldn't suffice then. As said in the description, and as discussed during the development of the XSA-400 series, further locking would need adding then. Jan
Re: [PATCH v5 2/2] xen: Populate xen.lds.h and make use of its macros
Hi Michal, On 11/04/2022 08:03, Michal Orzel wrote: Populate header file xen.lds.h with the first portion of macros storing constructs common to x86 and arm linker scripts. Replace the original constructs with these helpers. No functional improvements to x86 linker script. Making use of common macros improves arm linker script with: - explicit list of debug sections that otherwise are seen as "orphans" by the linker. This will allow to fix issues after enabling linker option --orphan-handling one day, - extended list of discarded section to include: .discard, destructors related sections, .fini_array which can reference .text.exit, - sections not related to debugging that are placed by ld.lld. Even though we do not support linking with LLD on Arm, these sections do not cause problem to GNU ld, As we are replacing hardcoded boundary specified as an argument to ALIGN function with POINTER_ALIGN, this changes the alignment in HYPFS_PARAM construct for arm32 from 8 to 4. It is fine as there are no 64bit values used in struct param_hypfs. Please note that this patch does not aim to perform the full sync up between the linker scripts. It creates a base for further work. Signed-off-by: Michal Orzel Reviewed-by: Jan Beulich Reviewed-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v5 1/2] xen: Introduce a header to store common linker scripts content
Hi Michal, On 11/04/2022 08:02, Michal Orzel wrote: Both x86 and arm linker scripts share quite a lot of common content. It is difficult to keep syncing them up, thus introduce a new header in include/xen called xen.lds.h to store the internals mutual to all the linker scripts. Include this header in linker scripts for x86 and arm. This patch serves as an intermediate step before populating xen.lds.h and making use of its content in the linker scripts later on. Signed-off-by: Michal Orzel Acked-by: Jan Beulich Acked-by: Julien Grall Cheers, -- Julien Grall
Re: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes
On 11.04.2022 12:11, Henry Wang wrote: > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné >>> >>> May I ask for an ack or otherwise for the changelog entry, please? >> >> Ping? This is the only thing missing for me to commit the remaining >> parts of this series. > > Sorry for the late response, the previous e-mail that you directly > "to"ed me fell through the cracks somehow. > > Acked-by: Henry Wang Thanks. > Since you also mentioned the changelog entry, I will take a note of this > series and we can have a discussion about adding it when we do the > next Xen release (4.17). Would that sound ok with you? "Adding it" where? Maybe you mean to the release notes, but that's not entirely clear. Jan
[xen-unstable test] 169292: regressions - FAIL
flight 169292 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169292/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 169273 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10 fail in 169273 pass in 169292 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 169273 pass in 169292 test-armhf-armhf-xl 13 debian-fixup fail pass in 169273 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl-seattle 16 saverestore-support-check fail in 169273 never pass test-arm64-arm64-xl 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl 16 saverestore-support-check fail in 169273 never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail in 169273 never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 169273 never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 169273 never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail in 169273 never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail in 169273 never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 169273 never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail in 169273 never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail in 169273 never pass test-armhf-armhf-xl 15 migrate-support-check fail in 169273 never pass test-armhf-armhf-xl 16 saverestore-support-check fail in 169273 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169273 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169273 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169273 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169273 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169273 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169273 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169273 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169273 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169273 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169273 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169273 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169273 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf
RE: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes
Hi Jan, > >>> Signed-off-by: Jan Beulich > >> > >> Acked-by: Roger Pau Monné > > > > May I ask for an ack or otherwise for the changelog entry, please? > > Ping? This is the only thing missing for me to commit the remaining > parts of this series. Sorry for the late response, the previous e-mail that you directly "to"ed me fell through the cracks somehow. Acked-by: Henry Wang Since you also mentioned the changelog entry, I will take a note of this series and we can have a discussion about adding it when we do the next Xen release (4.17). Would that sound ok with you? Kind regards, Henry > > Thanks, Jan
Re: [PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks
On 11/04/2022 10:35, Jan Beulich wrote: > Prior extension of these functions to enable per-device quarantine page > tables already didn't add more locking there, but merely left in place > what had been there before. But really locking is unnecessary here: > We're running with pcidevs_lock held (i.e. multiple invocations of the > same function [or their teardown equivalents] are impossible, and hence > there are no "local" races), while all consuming of the data being > populated here can't race anyway due to happening sequentially > afterwards. See also the comment in struct arch_pci_dev. > > Signed-off-by: Jan Beulich It is only legitimate to drop these calls if you delete the mapping_lock entirely. Otherwise you're breaking the semantics of mapping_lock. Your argument of "well this is already guarded by the pci lock" means that these are uncontended lock/unlock operations, and therefore not interesting to drop in the first place. This patch is specifically setting us up for an XSA in the future when the behaviour of the the PCI lock changes, the fix for which will be revert this patch. ~Andrew
[ovmf test] 169300: regressions - FAIL
flight 169300 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169300/ 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 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf dab96cf02e3be378310dd1bce119b0fac6fac958 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 41 days Failing since168258 2022-03-01 01:55:31 Z 41 days 321 attempts Testing same since 169287 2022-04-10 21:10:35 Z0 days 10 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4791 lines long.)
Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes
On 06.04.2022 16:23, Jan Beulich wrote: > On 05.04.2022 10:45, Roger Pau Monné wrote: >> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote: >>> GrUB2 can be told to leave the screen in the graphics mode it has been >>> using (or any other one), via "set gfxpayload=keep" (or suitable >>> variants thereof). In this case we can avoid doing another mode switch >>> ourselves. This in particular avoids possibly setting the screen to a >>> less desirable mode: On one of my test systems the set of modes >>> reported available by the VESA BIOS depends on whether the interposed >>> KVM switch has that machine set as the active one. If it's not active, >>> only modes up to 1024x768 get reported, while when active 1280x1024 >>> modes are also included. For things to always work with an explicitly >>> specified mode (via the "vga=" option), that mode therefore needs be a >>> 1024x768 one. >>> >>> For some reason this only works for me with "multiboot2" (and >>> "module2"); "multiboot" (and "module") still forces the screen into text >>> mode, despite my reading of the sources suggesting otherwise. >>> >>> For starters I'm limiting this to graphics modes; I do think this ought >>> to also work for text modes, but >>> - I can't tell whether GrUB2 can set any text mode other than 80x25 >>> (I've only found plain "text" to be valid as a "gfxpayload" setting), >>> - I'm uncertain whether supporting that is worth it, since I'm uncertain >>> how many people would be running their systems/screens in text mode, >>> - I'd like to limit the amount of code added to the realmode trampoline. >>> >>> For starters I'm also limiting mode information retrieval to raw BIOS >>> accesses. This will allow things to work (in principle) also with other >>> boot environments where a graphics mode can be left in place. The >>> downside is that this then still is dependent upon switching back to >>> real mode, so retrieving the needed information from multiboot info is >>> likely going to be desirable down the road. >>> >>> Signed-off-by: Jan Beulich >> >> Acked-by: Roger Pau Monné > > May I ask for an ack or otherwise for the changelog entry, please? Ping? This is the only thing missing for me to commit the remaining parts of this series. Thanks, Jan
[PATCH v4] IOMMU/x86: disallow device assignment to PoD guests
While it is okay for IOMMU page tables to be set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.
Also use the new function to replace p2m_pod_entry_count(): Its unlocked
access to p2m->pod.entry_count wasn't really okay (irrespective of the
result being stale by the time the caller gets to see it). Nor was the
use of that function in line with the immediately preceding comment: A
PoD guest isn't just one with a non-zero entry count, but also one with
a non-empty cache (e.g. prior to actually launching the guest).
To allow the tool stack to see a consistent snapshot of PoD state, move
the tail of XENMEM_{get,set}_pod_target handling into a function, adding
proper locking there.
In libxl take the liberty to use the new local variable r also for a
pre-existing call into libxc.
Signed-off-by: Jan Beulich
---
If p2m->pod.entry_count == p2m->pod.count it is in principle possible to
permit device assignment by actively resolving all remaining PoD entries.
Initially I thought this was introduced by f89f555827a6 ("remove late
(on-demand) construction of IOMMU page tables"), but without
arch_iommu_use_permitted() checking for PoD I think the issue has been
there before that.
---
v4: Drop tool stack side change (superseded by 07449ecfa425). Extend VM
event related paragraph of description.
v3: In p2m_pod_set_mem_target() move check down.
v2: New.
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -20,6 +20,7 @@
*/
#include
+#include
#include
#include
#include
@@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
ASSERT( pod_target >= p2m->pod.count );
-ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
+if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+ret = -ENOTEMPTY;
+else
+ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
out:
pod_unlock(p2m);
@@ -368,6 +372,23 @@ out:
return ret;
}
+void p2m_pod_get_mem_target(const struct domain *d, xen_pod_target_t *target)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+ASSERT(is_hvm_domain(d));
+
+pod_lock(p2m);
+lock_page_alloc(p2m);
+
+target->tot_pages = domain_tot_pages(d);
+target->pod_cache_pages = p2m->pod.count;
+target->pod_entries = p2m->pod.entry_count;
+
+unlock_page_alloc(p2m);
+pod_unlock(p2m);
+}
+
int p2m_pod_empty_cache(struct domain *d)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1391,6 +1412,9 @@ guest_physmap_mark_populate_on_demand(st
if ( !paging_mode_translate(d) )
return -EINVAL;
+if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+return -ENOTEMPTY;
+
do {
rc = mark_populate_on_demand(d, gfn, chunk_order);
@@ -1412,3 +1436,20 @@ void p2m_pod_init(struct p2m_domain *p2m
for ( i = 0; i < ARRAY_SIZE(p2m->pod.mrp.list); ++i )
p2m->pod.mrp.list[i] = gfn_x(INVALID_GFN);
}
+
+bool p2m_pod_active(const struct domain *d)
+{
+struct p2m_domain *p2m;
+bool res;
+
+if ( !is_hvm_domain(d) )
+return false;
+
+p2m = p2m_get_hostp2m(d);
+
+pod_lock(p2m);
+res = p2m->pod.entry_count | p2m->pod.count;
+pod_unlock(p2m);
+
+return res;
+}
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4804,7 +4804,6 @@ long arch_memory_op(unsigned long cmd, X
{
xen_pod_target_t target;
struct domain *d;
-struct p2m_domain *p2m;
if ( copy_from_guest(&target, arg, 1) )
return -EFAULT;
@@ -4835,10 +4834,7 @@ long arch_memory_op(unsigned long cmd, X
}
else if ( rc >= 0 )
{
-p2m = p2m_get_hostp2m(d);
-target.tot_pages = domain_tot_pages(d);
-target.pod_cache_pages = p2m->pod.count;
-target.pod_entries = p2m->pod.entry_count;
+p2m_pod_get_mem_target(d, &target);
if ( __copy_to_guest(arg, &target, 1) )
rc = -EFAULT;
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -639,7 +639,7 @@ int vm_event_domctl(struct domain *d, st
rc = -EXDEV;
/* Disallow paging in a PoD guest */
-if ( p2m_pod_entry_count(p2m_get_hostp2m(d)) )
+if ( p2m_pod_active(d) )
break;
/* domain_pause() not required here, see XSA-99 */
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -513,11 +513,12 @@ bool arch_iommu_use_permitted(const stru
{
/*
* Prevent device assign if mem paging, mem sharing or log-dirty
- * have been enabled for this domain.
+ * have been enabled for this domain, or if PoD is still in active use.
*/
return d == dom_io ||
(likely(!mem_sharing_enabled(d)) &&
likely(!mem_paging_en
[PATCH 6/8] IOMMU: log appropriate SBDF
To handle phantom devices, several functions are passed separate "devfn"
arguments besides a PCI device. In such cases we want to log the phantom
device's coordinates instead of the main one's. (Note that not all of
the instances being changed are fallout from the referenced commit.)
Fixes: 1ee1441835f4 ("print: introduce a format specifier for pci_sbdf_t")
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -291,7 +291,8 @@ void amd_iommu_flush_iotlb(u8 devfn, con
if ( !iommu )
{
-AMD_IOMMU_WARN("can't find IOMMU for %pp\n", &pdev->sbdf);
+AMD_IOMMU_WARN("can't find IOMMU for %pp\n",
+ &PCI_SBDF3(pdev->seg, pdev->bus, devfn));
return;
}
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -461,7 +461,7 @@ static int cf_check reassign_device(
if ( !iommu )
{
AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be assigned to %pd\n",
- &pdev->sbdf, target);
+ &PCI_SBDF3(pdev->seg, pdev->bus, devfn), target);
return -ENODEV;
}
@@ -497,8 +497,8 @@ static int cf_check reassign_device(
return rc;
}
-AMD_IOMMU_DEBUG("Re-assign %pp from dom%d to dom%d\n",
-&pdev->sbdf, source->domain_id, target->domain_id);
+AMD_IOMMU_DEBUG("Re-assign %pp from %pd to %pd\n",
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), source, target);
return 0;
}
@@ -575,7 +575,7 @@ static int cf_check amd_iommu_add_device
}
AMD_IOMMU_WARN("no IOMMU for %pp; cannot be handed to %pd\n",
-&pdev->sbdf, pdev->domain);
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), pdev->domain);
return -ENODEV;
}
@@ -618,7 +618,7 @@ static int cf_check amd_iommu_add_device
ivrs_mappings[ivrs_mappings[bdf].dte_requestor_id].unity_map,
0) )
AMD_IOMMU_WARN("%pd: unity mapping failed for %pp\n",
- pdev->domain, &pdev->sbdf);
+ pdev->domain, &PCI_SBDF2(pdev->seg, bdf));
if ( iommu_quarantine && pdev->arch.pseudo_domid == DOMID_INVALID )
{
@@ -651,7 +651,7 @@ static int cf_check amd_iommu_remove_dev
if ( !iommu )
{
AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be removed from
%pd\n",
-&pdev->sbdf, pdev->domain);
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), pdev->domain);
return -ENODEV;
}
@@ -664,7 +664,7 @@ static int cf_check amd_iommu_remove_dev
pdev->domain,
ivrs_mappings[ivrs_mappings[bdf].dte_requestor_id].unity_map) )
AMD_IOMMU_WARN("%pd: unity unmapping failed for %pp\n",
- pdev->domain, &pdev->sbdf);
+ pdev->domain, &PCI_SBDF2(pdev->seg, bdf));
amd_iommu_quarantine_teardown(pdev);
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1406,7 +1406,7 @@ static int iommu_add_device(struct pci_d
rc = iommu_call(hd->platform_ops, add_device, devfn, pci_to_dev(pdev));
if ( rc )
printk(XENLOG_WARNING "IOMMU: add %pp failed (%d)\n",
- &pdev->sbdf, rc);
+ &PCI_SBDF3(pdev->seg, pdev->bus, devfn), rc);
}
}
@@ -1451,7 +1451,8 @@ static int iommu_remove_device(struct pc
if ( !rc )
continue;
-printk(XENLOG_ERR "IOMMU: remove %pp failed (%d)\n", &pdev->sbdf, rc);
+printk(XENLOG_ERR "IOMMU: remove %pp failed (%d)\n",
+ &PCI_SBDF3(pdev->seg, pdev->bus, devfn), rc);
return rc;
}
[PATCH 8/8] PCI: replace "secondary" flavors of PCI_{DEVFN,BDF,SBDF}()
At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper macros, which aren't supposed to be
used from the outside).
In parse_ppr_log_entry() take the opportunity and drop two local
variables and convert an assignment to an initializer.
In VT-d code fold a number of bus+devfn comparison pairs into a single
BDF comparison.
No change to generated code for the vast majority of the adjustments.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4902,7 +4902,7 @@ int cf_check mmcfg_intercept_write(
if ( pci_conf_write_intercept(mmio_ctxt->seg, mmio_ctxt->bdf,
offset, bytes, p_data) >= 0 )
pci_mmcfg_write(mmio_ctxt->seg, PCI_BUS(mmio_ctxt->bdf),
-PCI_DEVFN2(mmio_ctxt->bdf), offset, bytes,
+PCI_DEVFN(mmio_ctxt->bdf), offset, bytes,
*(uint32_t *)p_data);
return X86EMUL_OKAY;
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -90,7 +90,7 @@ int pci_conf_write_intercept(unsigned in
pcidevs_lock();
-pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN2(bdf));
+pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN(bdf));
if ( pdev )
rc = pci_msi_conf_write_intercept(pdev, reg, size, data);
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -313,7 +313,7 @@ static int __init pci_mmcfg_check_hostbr
for (i = 0; !name && i < ARRAY_SIZE(pci_mmcfg_probes); i++) {
bus = pci_mmcfg_probes[i].bus;
devfn = pci_mmcfg_probes[i].devfn;
-l = pci_conf_read32(PCI_SBDF3(0, bus, devfn), 0);
+l = pci_conf_read32(PCI_SBDF(0, bus, devfn), 0);
vendor = l & 0x;
device = (l >> 16) & 0x;
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -27,8 +27,8 @@ static int cf_check get_reserved_device_
xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt)
{
struct get_reserved_device_memory *grdm = ctxt;
-uint32_t sbdf = PCI_SBDF3(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
- grdm->map.dev.pci.devfn).sbdf;
+uint32_t sbdf = PCI_SBDF(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
+ grdm->map.dev.pci.devfn).sbdf;
if ( !(grdm->map.flags & XENMEM_RDM_ALL) && (sbdf != id) )
return 0;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1055,8 +1055,8 @@ static int cf_check get_reserved_device_
xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt)
{
struct get_reserved_device_memory *grdm = ctxt;
-uint32_t sbdf = PCI_SBDF3(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
- grdm->map.dev.pci.devfn).sbdf;
+uint32_t sbdf = PCI_SBDF(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
+ grdm->map.dev.pci.devfn).sbdf;
if ( !(grdm->map.flags & XENMEM_RDM_ALL) && (sbdf != id) )
return 0;
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -96,7 +96,7 @@ static void __init add_ivrs_mapping_entr
if ( !ivrs_mappings[alias_id].intremap_table )
panic("No memory for %pp's IRT\n",
- &PCI_SBDF2(iommu->seg, alias_id));
+ &PCI_SBDF(iommu->seg, alias_id));
}
}
@@ -790,7 +790,7 @@ static u16 __init parse_ivhd_device_spec
}
AMD_IOMMU_DEBUG("IVHD Special: %pp variety %#x handle %#x\n",
-&PCI_SBDF2(seg, bdf), special->variety, special->handle);
+&PCI_SBDF(seg, bdf), special->variety, special->handle);
add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, 0, true,
iommu);
@@ -816,7 +816,7 @@ static u16 __init parse_ivhd_device_spec
AMD_IOMMU_DEBUG("IVHD: Command line override present for IO-APIC
%#x"
"(IVRS: %#x devID %pp)\n",
ioapic_sbdf[idx].id, special->handle,
-&PCI_SBDF2(seg, bdf));
+&PCI_SBDF(seg, bdf));
break;
}
@@ -888,7 +888,7 @@ static u16 __init parse_ivhd_device_spec
AMD_IOMMU_DEBUG("IVHD: Command line override present for HPET %#x "
"(IVRS: %#x devID %pp)\n",
hpet_sbdf.id, special->handle,
-&PCI_SBDF2(seg, bdf));
+&PCI_SBDF(seg, bdf));
break;
case HPET_NONE:
/* set device id of hpet */
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -40,7 +40,7 @@ static void send_iommu_command(struct am
IOMMU_RIN
[PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()
There's no good reason to use these when we already have a pci_sbdf_t type object available. This extends to the use of PCI_BUS() in pci_ecam_map_bus() as well. No change to generated code (with gcc11 at least, and I have to admit that I didn't expect compilers to necessarily be able to spot the optimization potential on the original code). Signed-off-by: Jan Beulich --- Note that the Arm changes are "blind": I haven't been able to spot a way to at least compile test the changes there; the code looks to be entirely dead. --- a/xen/arch/arm/pci/ecam.c +++ b/xen/arch/arm/pci/ecam.c @@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc container_of(bridge->ops, const struct pci_ecam_ops, pci_ops); unsigned int devfn_shift = ops->bus_shift - 8; void __iomem *base; - -unsigned int busn = PCI_BUS(sbdf.bdf); +unsigned int busn = sbdf.bus; if ( busn < cfg->busn_start || busn > cfg->busn_end ) return NULL; @@ -37,7 +36,7 @@ void __iomem *pci_ecam_map_bus(struct pc busn -= cfg->busn_start; base = cfg->win + (busn << ops->bus_shift); -return base + (PCI_DEVFN2(sbdf.bdf) << devfn_shift) + where; +return base + (sbdf.df << devfn_shift) + where; } bool __init pci_ecam_need_p2m_hwdom_mapping(struct domain *d, --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -839,7 +839,7 @@ static int msix_capability_init(struct p pbus = dev->info.physfn.bus; pslot = PCI_SLOT(dev->info.physfn.devfn); pfunc = PCI_FUNC(dev->info.physfn.devfn); -vf = PCI_BDF2(dev->bus, dev->devfn); +vf = dev->sbdf.bdf; } table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf); --- a/xen/drivers/passthrough/vtd/qinval.c +++ b/xen/drivers/passthrough/vtd/qinval.c @@ -267,7 +267,7 @@ int qinval_device_iotlb_sync(struct vtd_ qinval_entry->q.dev_iotlb_inv_dsc.lo.res_1 = 0; qinval_entry->q.dev_iotlb_inv_dsc.lo.max_invs_pend = pdev->ats.queue_depth; qinval_entry->q.dev_iotlb_inv_dsc.lo.res_2 = 0; -qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = PCI_BDF2(pdev->bus, pdev->devfn); +qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = pdev->sbdf.bdf; qinval_entry->q.dev_iotlb_inv_dsc.lo.res_3 = 0; qinval_entry->q.dev_iotlb_inv_dsc.hi.size = size;
[PATCH 5/8] AMD/IOMMU: replace a few PCI_BDF2()
struct pci_dev has the wanted value directly available; use it. Note
that this fixes a - imo benign - mistake in reassign_device(): The unity
map removal ought to be based on the passed in devfn (as is the case on
the establishing side). This is benign because the mappings would be
removed anyway a little later, when the "main" device gets processed.
While there also limit the scope of two variables in that function.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -287,7 +287,7 @@ void amd_iommu_flush_iotlb(u8 devfn, con
if ( !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn) )
return;
-iommu = find_iommu_for_device(pdev->seg, PCI_BDF2(pdev->bus, pdev->devfn));
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
if ( !iommu )
{
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -617,7 +617,7 @@ int cf_check amd_iommu_msi_msg_update_ir
unsigned int i, nr = 1;
u32 data;
-bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+bdf = pdev ? pdev->sbdf.bdf : hpet_sbdf.bdf;
seg = pdev ? pdev->seg : hpet_sbdf.seg;
iommu = _find_iommu_for_device(seg, bdf);
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -455,11 +455,9 @@ static int cf_check reassign_device(
struct pci_dev *pdev)
{
struct amd_iommu *iommu;
-int bdf, rc;
-const struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
+int rc;
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
if ( !iommu )
{
AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be assigned to %pd\n",
@@ -489,6 +487,9 @@ static int cf_check reassign_device(
*/
if ( !is_hardware_domain(source) )
{
+const struct ivrs_mappings *ivrs_mappings =
get_ivrs_mappings(pdev->seg);
+unsigned int bdf = PCI_BDF2(pdev->bus, devfn);
+
rc = amd_iommu_reserve_domain_unity_unmap(
source,
ivrs_mappings[get_dma_requestor_id(pdev->seg,
bdf)].unity_map);
@@ -558,13 +559,11 @@ static int cf_check amd_iommu_add_device
if ( !pdev->domain )
return -EINVAL;
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-
for_each_amd_iommu(iommu)
-if ( pdev->seg == iommu->seg && bdf == iommu->bdf )
+if ( pdev->seg == iommu->seg && pdev->sbdf.bdf == iommu->bdf )
return is_hardware_domain(pdev->domain) ? 0 : -ENODEV;
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
if ( unlikely(!iommu) )
{
/* Filter bridge devices. */
@@ -648,8 +647,7 @@ static int cf_check amd_iommu_remove_dev
if ( !pdev->domain )
return -EINVAL;
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
if ( !iommu )
{
AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be removed from
%pd\n",
