Re: [PATCH 2/7] ipmi: simplify sysctl registration
On Thu, Mar 02, 2023 at 12:46:07PM -0800, Luis Chamberlain wrote:
> register_sysctl_table() is a deprecated compatibility wrapper.
> register_sysctl() can do the directory creation for you so just use
> that.
Thanks, I have included this in my tree for the next merge window.
-corey
>
> Signed-off-by: Luis Chamberlain
> ---
> drivers/char/ipmi/ipmi_poweroff.c | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_poweroff.c
> b/drivers/char/ipmi/ipmi_poweroff.c
> index 163ec9749e55..870659d91db2 100644
> --- a/drivers/char/ipmi/ipmi_poweroff.c
> +++ b/drivers/char/ipmi/ipmi_poweroff.c
> @@ -659,20 +659,6 @@ static struct ctl_table ipmi_table[] = {
> { }
> };
>
> -static struct ctl_table ipmi_dir_table[] = {
> - { .procname = "ipmi",
> - .mode = 0555,
> - .child= ipmi_table },
> - { }
> -};
> -
> -static struct ctl_table ipmi_root_table[] = {
> - { .procname = "dev",
> - .mode = 0555,
> - .child= ipmi_dir_table },
> - { }
> -};
> -
> static struct ctl_table_header *ipmi_table_header;
> #endif /* CONFIG_PROC_FS */
>
> @@ -689,7 +675,7 @@ static int __init ipmi_poweroff_init(void)
> pr_info("Power cycle is enabled\n");
>
> #ifdef CONFIG_PROC_FS
> - ipmi_table_header = register_sysctl_table(ipmi_root_table);
> + ipmi_table_header = register_sysctl("dev/ipmi", ipmi_table);
> if (!ipmi_table_header) {
> pr_err("Unable to register powercycle sysctl\n");
> rv = -ENOMEM;
> --
> 2.39.1
>
Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list
On Wed, Apr 27, 2022 at 07:49:15PM -0300, Guilherme G. Piccoli wrote: > This patch renames the panic_notifier_list to panic_pre_reboot_list; > the idea is that a subsequent patch will refactor the panic path > in order to better split the notifiers, running some of them very > early, some of them not so early [but still before kmsg_dump()] and > finally, the rest should execute late, after kdump. The latter ones > are now in the panic pre-reboot list - the name comes from the idea > that these notifiers execute before panic() attempts rebooting the > machine (if that option is set). > > We also took the opportunity to clean-up useless header inclusions, > improve some notifier block declarations (e.g. in ibmasm/heartbeat.c) > and more important, change some priorities - we hereby set 2 notifiers > to run late in the list [iss_panic_event() and the IPMI panic_event()] > due to the risks they offer (may not return, for example). > Proper documentation is going to be provided in a subsequent patch, > that effectively refactors the panic path. For the IPMI portion: Acked-by: Corey Minyard Note that the IPMI panic_event() should always return, but it may take some time, especially if the IPMI controller is no longer functional. So the risk of a long delay is there and it makes sense to move it very late. -corey > > Cc: Alex Elder > Cc: Alexander Gordeev > Cc: Anton Ivanov > Cc: Benjamin Herrenschmidt > Cc: Bjorn Andersson > Cc: Boris Ostrovsky > Cc: Chris Zankel > Cc: Christian Borntraeger > Cc: Corey Minyard > Cc: Dexuan Cui > Cc: "H. Peter Anvin" > Cc: Haiyang Zhang > Cc: Heiko Carstens > Cc: Helge Deller > Cc: Ivan Kokshaysky > Cc: "James E.J. Bottomley" > Cc: James Morse > Cc: Johannes Berg > Cc: Juergen Gross > Cc: "K. Y. Srinivasan" > Cc: Mathieu Poirier > Cc: Matt Turner > Cc: Mauro Carvalho Chehab > Cc: Max Filippov > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Pavel Machek > Cc: Richard Henderson > Cc: Richard Weinberger > Cc: Robert Richter > Cc: Stefano Stabellini > Cc: Stephen Hemminger > Cc: Sven Schnelle > Cc: Tony Luck > Cc: Vasily Gorbik > Cc: Wei Liu > Signed-off-by: Guilherme G. Piccoli > --- > > Notice that, with this name change, out-of-tree code that relies in the global > exported "panic_notifier_list" will fail to build. We could easily keep the > retro-compatibility by making the old symbol to still exist and point to the > pre_reboot list (or even, keep the old naming). > > But our design choice was to allow the breakage, making users rethink their > notifiers, adding them in the list that fits best. If that wasn't a good > decision, we're open to change it, of course. > Thanks in advance for the review! > > arch/alpha/kernel/setup.c | 4 ++-- > arch/parisc/kernel/pdc_chassis.c | 3 +-- > arch/powerpc/kernel/setup-common.c| 2 +- > arch/s390/kernel/ipl.c| 4 ++-- > arch/um/drivers/mconsole_kern.c | 2 +- > arch/um/kernel/um_arch.c | 2 +- > arch/x86/xen/enlighten.c | 2 +- > arch/xtensa/platforms/iss/setup.c | 4 ++-- > drivers/char/ipmi/ipmi_msghandler.c | 12 +++- > drivers/edac/altera_edac.c| 3 +-- > drivers/hv/vmbus_drv.c| 4 ++-- > drivers/leds/trigger/ledtrig-panic.c | 3 +-- > drivers/misc/ibmasm/heartbeat.c | 16 +--- > drivers/net/ipa/ipa_smp2p.c | 5 ++--- > drivers/parisc/power.c| 4 ++-- > drivers/remoteproc/remoteproc_core.c | 6 -- > drivers/s390/char/con3215.c | 2 +- > drivers/s390/char/con3270.c | 2 +- > drivers/s390/char/sclp_con.c | 2 +- > drivers/s390/char/sclp_vt220.c| 2 +- > drivers/staging/olpc_dcon/olpc_dcon.c | 6 -- > drivers/video/fbdev/hyperv_fb.c | 4 ++-- > include/linux/panic_notifier.h| 2 +- > kernel/panic.c| 9 - > 24 files changed, 54 insertions(+), 51 deletions(-) > > diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c > index d88bdf852753..8ace0d7113b6 100644 > --- a/arch/alpha/kernel/setup.c > +++ b/arch/alpha/kernel/setup.c > @@ -472,8 +472,8 @@ setup_arch(char **cmdline_p) > } > > /* Register a call for panic conditions. */ > - atomic_notifier_chain_register(&panic_notifier_list, > - &alpha_panic_block); > + atomic_notifier_chain_register(&panic_pre_reboot_list, > + &alpha_panic_block); > > #ifndef alpha_using_srm > /* Assume that we've boo
Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel
On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote: > On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote: > > > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > > > On Mon, 15 Jun 2020, Christopher Clark wrote: > > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik > > > > wrote: > > > > > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard > > > > > wrote: > > > > > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled > > > > > > onto > > > > > > existing sd cards, and this was working fine. I finally got to a > > > > > > full > > > > > > yocto build of the system, and it didn't boot. > > > > > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > > > might suggest it's booting without any console output. > > > > > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > > > works fine, whereas I see no console output from the kernel once Xen > > > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With > > > > > > everything > > > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > > > version does not work. It also didn't work if I completely removed > > > > > > the > > > > > > overlay. The base device trees are the same between the two > > > > > > kernels. > > > > > > > > > > > > Looking at the overlay changes between the versions and Xen source, > > > > > > I > > > > > > can't trace down anything that would cause an issue. Has anyone > > > > > > seen > > > > > > this issue of have any ideas? > > > > > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to > > > > > 5.6.x: > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and > > > > > Stefano). > > > > > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > > > you guys have working ok? > > > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > > > source tree of that branch at the point the kernel version was bumped > > > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > > > config? > > > > > > I don't know if that is the issue but beware that some device trees > > > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > > > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > > > line. > > > > I already have that set as part of the boot process, but it still > > doesn't print anything out once Xen is started. > > > > I tried the 5.6 device tree, and no help there, eithers. I'm wondering > > if everyone is still running with the 4.19 device trees. > > As I pointed out in the EVE link above -- we're very happily running > with 5.6 device trees. They are, of course, taken from RPI kernel > tree. Ok, what version of Xen are you running? I'm using 4.13 with the Pi patches, but I have not tried the master branch. -corey > > Thanks, > Roman.
Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel
On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > On Mon, 15 Jun 2020, Christopher Clark wrote: > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard > > > wrote: > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > existing sd cards, and this was working fine. I finally got to a full > > > > yocto build of the system, and it didn't boot. > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > might suggest it's booting without any console output. > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > works fine, whereas I see no console output from the kernel once Xen > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > version does not work. It also didn't work if I completely removed the > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > this issue of have any ideas? > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to > > > 5.6.x: > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > you guys have working ok? > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > source tree of that branch at the point the kernel version was bumped > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > config? > > I don't know if that is the issue but beware that some device trees > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > line. I already have that set as part of the boot process, but it still doesn't print anything out once Xen is started. I tried the 5.6 device tree, and no help there, eithers. I'm wondering if everyone is still running with the 4.19 device trees. The device tree differences between 4.19 and 5.4 are rather large, unfortunately. -corey
Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel
I had been working on Xen on the Pi4 by throwing kernels I compiled onto existing sd cards, and this was working fine. I finally got to a full yocto build of the system, and it didn't boot. In fact, Xen didn't print anything at all, and nothing happens that might suggest it's booting without any console output. I traced the issue down to the vc4-fkms-v3d dtoverly. With everything else the same, the 4.19 version of that overlay works, and the 5.4 version does not work. It also didn't work if I completely removed the overlay. The base device trees are the same between the two kernels. Looking at the overlay changes between the versions and Xen source, I can't trace down anything that would cause an issue. Has anyone seen this issue of have any ideas? -corey
Re: [PATCH] xen/rpi4: implement watchdog-based reset
On Thu, Jun 04, 2020 at 09:15:33AM +0100, Julien Grall wrote: > Hi, > > On 04/06/2020 01:15, Corey Minyard wrote: > > On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote: > > > Touching the watchdog is required to be able to reboot the board. > > > > > > The implementation is based on > > > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > > > Ah, I was looking at this just today, as it had been annoying me > > greatly. This works for me, so: > > > > Tested-by: Corey Minyard > > > > However, I was wondering if it might be better to handle this by failing > > the operation in xen and passing it back to dom0 to do. On the Pi you > > send a firmware message to reboot, and that seems like too much to do in > > Xen, but it would seem possible to send this back to dom0. > I don't think this is possible in the current setup. Xen will usually > restart the platform if Dom0 requested a clean reboot or crashed. So the > domain wouldn't be in state to service such call. Ok, I hadn't looked at Xen yet, I didn't know how much shutdown of dom0 happens on a reset. > > > Just a > > thought, as it might be a more general fix for other devices in the same > > situation. > > What are the devices you have in mind? Nothing in particular, but other systems might have the same issue. I guess you have ACPI implemented on x86 already. It just seemed that Linux already has to be able to do this, and passing the buck back there might be a more general solution. Thanks, -corey > > Cheers, > > -- > Julien Grall
Re: [PATCH] xen/rpi4: implement watchdog-based reset
On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote:
> Touching the watchdog is required to be able to reboot the board.
>
> The implementation is based on
> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.
Ah, I was looking at this just today, as it had been annoying me
greatly. This works for me, so:
Tested-by: Corey Minyard
However, I was wondering if it might be better to handle this by failing
the operation in xen and passing it back to dom0 to do. On the Pi you
send a firmware message to reboot, and that seems like too much to do in
Xen, but it would seem possible to send this back to dom0. Just a
thought, as it might be a more general fix for other devices in the same
situation.
Thanks,
-corey
>
> Signed-off-by: Stefano Stabellini
> ---
> xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++
> 1 file changed, 60 insertions(+)
>
> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
> b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> index f5ae58a7d5..0214ae2b3c 100644
> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> @@ -18,6 +18,10 @@
> */
>
> #include
> +#include
> +#include
> +#include
> +#include
>
> static const char *const rpi4_dt_compat[] __initconst =
> {
> @@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[]
> __initconst =
> * The aux peripheral also shares a page with the aux UART.
> */
> DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
> +/* Special device used for rebooting */
> +DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
> { /* sentinel */ },
> };
>
> +
> +#define PM_PASSWORD 0x5a00
> +#define PM_RSTC 0x1c
> +#define PM_WDOG 0x24
> +#define PM_RSTC_WRCFG_FULL_RESET0x0020
> +#define PM_RSTC_WRCFG_CLR 0xffcf
> +
> +static void __iomem *rpi4_map_watchdog(void)
> +{
> +void __iomem *base;
> +struct dt_device_node *node;
> +paddr_t start, len;
> +int ret;
> +
> +node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
> +if ( !node )
> +return NULL;
> +
> +ret = dt_device_get_address(node, 0, &start, &len);
> +if ( ret )
> +{
> +dprintk(XENLOG_ERR, "Cannot read watchdog register address\n");
> +return NULL;
> +}
> +
> +base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
> +if ( !base )
> +{
> +dprintk(XENLOG_ERR, "Unable to map watchdog register!\n");
> +return NULL;
> +}
> +
> +return base;
> +}
> +
> +static void rpi4_reset(void)
> +{
> +u32 val;
> +void __iomem *base = rpi4_map_watchdog();
> +if ( !base )
> +return;
> +
> +/* use a timeout of 10 ticks (~150us) */
> +writel(10 | PM_PASSWORD, base + PM_WDOG);
> +val = readl(base + PM_RSTC);
> +val &= PM_RSTC_WRCFG_CLR;
> +val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
> +writel(val, base + PM_RSTC);
> +
> +/* No sleeping, possibly atomic. */
> +mdelay(1);
> +}
> +
> PLATFORM_START(rpi4, "Raspberry Pi 4")
> .compatible = rpi4_dt_compat,
> .blacklist_dev = rpi4_blacklist_dev,
> +.reset = rpi4_reset,
> .dma_bitsize= 30,
> PLATFORM_END
>
> --
> 2.17.1
>
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, Jun 03, 2020 at 08:37:09AM -0700, Stefano Stabellini wrote: > On Wed, 3 Jun 2020, Corey Minyard wrote: > > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > > > On Tue, 2 Jun 2020, Corey Minyard wrote: > > > > Snip > > > > > > > > > > > > > whether > > > > > > > > > this was already done: > > > > > > > > > 1) Does the kernel boot on baremetal (i.e without Xen)? > > > > > > > > > This should > > > > > > > > > help > > > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > > > > > > 2) Swiotlb should not be necessary for basic dom0 boot > > > > > > > > > on Arm. Did > > > > > > > > > you try > > > > > > > > > to disable it? This should help to confirm whether swiotlb is > > > > > > > > > the > > > > > > > > > problem or > > > > > > > > > not. > > > > > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP > > > > > > > for dom0. So > > > > > > > this suggests swiotlb is doing some transformation on the DMA > > > > > > > address. > > > > > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb > > > > > > > seems to assume > > > > > > > the DMA address space and CPU address space is the same. Is RPI > > > > > > > using the > > > > > > > same address space? > > > > > > > > > > > > Another question, is the DMA request bounced? If so, are we sure > > > > > > the bounce > > > > > > buffer is in the first GB? > > > > > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > > > found another little related bug in the initialization of the > > > > > swiotlb-xen but now I am sure the memory is under 1GB > > > > > (0x3400-0x3800) > > > > > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > > > and I looked in the main kernel and didn't find anything that looked > > > > related. > > > > > > Yes, we have a patch series on the list for the Linux kernel to fix this > > > issue but it hasn't been merged yet: > > > > > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 > > > > Just FYI, I pulled the changes on top of > > https://github.com/raspberrypi/linux.git rpi-5.4.y > > Along with change > > 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* > > before the series so it applies on 5.4, and I was able to boot and > > create a domU. So: > > > > Tested-by: Corey Minyard > > > > At least on 5.4. If you think it would be valuable, I can test on > > rpi-5.7.y. > > I'd feel better adding your Tested-by to my next upstream submission of > the series if you could also test on 5.7. Thank you in advance! Well, rpi-5.7.y fails to bootup completely without Xen, and doesn't even display any console output on top of Xen :-(. So there are issues, but probably not with Xen. I did try rpi-5.6.y and it works. -corey > > > > I'll be integrating this in with our Pi Xen yocto layer at > > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen > > That's great!
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > On Tue, 2 Jun 2020, Corey Minyard wrote: > > Snip > > > > > > > > > whether > > > > > > > this was already done: > > > > > > > 1) Does the kernel boot on baremetal (i.e without Xen)? This > > > > > > > should > > > > > > > help > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > > 2) Swiotlb should not be necessary for basic dom0 boot on > > > > > > > Arm. Did > > > > > > > you try > > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > > problem or > > > > > > > not. > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for > > > > > dom0. So > > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to > > > > > assume > > > > > the DMA address space and CPU address space is the same. Is RPI using > > > > > the > > > > > same address space? > > > > > > > > Another question, is the DMA request bounced? If so, are we sure the > > > > bounce > > > > buffer is in the first GB? > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > found another little related bug in the initialization of the > > > swiotlb-xen but now I am sure the memory is under 1GB > > > (0x3400-0x3800) > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > and I looked in the main kernel and didn't find anything that looked > > related. > > Yes, we have a patch series on the list for the Linux kernel to fix this > issue but it hasn't been merged yet: > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 Just FYI, I pulled the changes on top of https://github.com/raspberrypi/linux.git rpi-5.4.y Along with change 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* before the series so it applies on 5.4, and I was able to boot and create a domU. So: Tested-by: Corey Minyard At least on 5.4. If you think it would be valuable, I can test on rpi-5.7.y. I'll be integrating this in with our Pi Xen yocto layer at https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen Thanks again, -corey
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
Snip > > > > > whether > > > > > this was already done: > > > > > 1) Does the kernel boot on baremetal (i.e without Xen)? This > > > > > should > > > > > help > > > > > to confirm whether the bug is Xen is related. > > > > > > > > Yes it boots > > > > > > > > > 2) Swiotlb should not be necessary for basic dom0 boot on Arm. > > > > > Did > > > > > you try > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > problem or > > > > > not. > > > > > > > > It boots disabling swiotlb-xen > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. > > > So > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to > > > assume > > > the DMA address space and CPU address space is the same. Is RPI using the > > > same address space? > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > buffer is in the first GB? > > Yes, it is. This is actually where we spent the last few days, and I > found another little related bug in the initialization of the > swiotlb-xen but now I am sure the memory is under 1GB (0x3400-0x3800) Was anything ever resolved on this issue? It just kind of ended for me, and I looked in the main kernel and didn't find anything that looked related. Thanks, -corey
Re: [PATCH for-4.14 3/3] xen/arm: plat: Allocate as much as possible memory below 1GB for dom0 for RPI
On Mon, May 18, 2020 at 08:36:08PM +, Volodymyr Babchuk wrote: > Hi Julien, > > On Mon, 2020-05-18 at 12:30 +0100, Julien Grall wrote: > > From: Julien Grall > > > > The raspberry PI 4 has devices that can only DMA into the first GB of > > the RAM. Therefore we want allocate as much as possible memory below 1GB > > for dom0. > > > > Use the recently introduced dma_bitsize field to specify the DMA width > > supported. > > > > Signed-off-by: Julien Grall > > Reported-by: Corey Minyard > > --- > > xen/arch/arm/platforms/brcm-raspberry-pi.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c > > b/xen/arch/arm/platforms/brcm-raspberry-pi.c > > index b697fa2c6c0e..ad5483437b31 100644 > > --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c > > +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c > > @@ -43,6 +43,7 @@ static const struct dt_device_match rpi4_blacklist_dev[] > > __initconst = > > PLATFORM_START(rpi4, "Raspberry Pi 4") > > .compatible = rpi4_dt_compat, > > .blacklist_dev = rpi4_blacklist_dev, > > +.dma_bitsize= 10, > > I'm confused. Should it be 30? Indeed it should. I just tested this series, and Linux fails to boot with this set to 10. With it set to 30 it works. With this set to 30, you can have a: Tested-by: Corey Minyard for all three patches. -corey > > > PLATFORM_END > > > > /*
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote: > Hi, > > On 02/05/2020 03:16, Corey Minyard wrote: > > On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote: > > > On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote: > > > > > > > > On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote: > > > > > Hi! > > > > > > > > > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock, > > > > > upstream kernel. The kernel itself works perfectly well > > > > > on the board. When I try booting it as Dom0 under Xen, > > > > > it goes into a stacktrace (attached). > > > > > > > > Getting Xen working on the Pi4 requires a lot of moving parts, and they > > > > all have to be right. > > > > > > Tell me about it! It is a pretty frustrating journey to align > > > everything just right. > > > On the other hand -- it seems worth to enable RPi as an ARM development > > > platform for Xen given how ubiquitous it is. > > > > > > Hence me trying to combine pristine upstream kernel (5.6.1) with > > > pristine upstream > > > Xen to enable 100% upstream developer workflow on RPi. > > > > > > > > Looking at what nice folks over at Dornerworks have previously > > > > > done to make RPi kernels boot as Dom0 I've come across these > > > > > 3 patches: > > > > > > > > > > https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux > > > > > > > > > > The first patch seems irrelevant (unless I'm missing something > > > > > really basic here). > > > > > > > > It might be irrelevant for your configuration, assuming that Xen gets > > > > the right information from EFI. I haven't tried EFI booting. > > > > > > I'd doing a bit of belt-and-suspenders strategy really -- I'm actually > > > using UEFI u-boot implementation that pre-populates device trees > > > and then I'm also forcing an extra copy of it to be load explicitly > > > via the GRUB devicetree command (GRUB runs as a UEFI payload). > > > > > > I also have access to the semi-official TianoCore RPi4 port that seems > > > to be working pretty well: https://github.com/pftf/RPi4/releases/tag/v1.5 > > > for booting all sort of UEFI payloads on RPi4. > > > > > > > > The 2nd patch applied with no issue (but > > > > > I don't think it is related) but the 3d patch failed to apply on > > > > > account of 5.6.1 kernel no longer having: > > > > > dev->archdata.dev_dma_ops > > > > > E.g. > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55 > > > > > > > > > > I've tried to emulate the effect of the patch by simply introducing > > > > > a static variable that would signal that we already initialized > > > > > dev->dma_ops -- but that didn't help at all. > > > > > > > > > > I'm CCing Jeff Kubascik to see if the original authors of that Corey > > > > > Minyard > > > > > to see if may be they have any suggestions on how this may be dealt > > > > > with. > > > > > > > > > > Any advice would be greatly appreciated! > > > > > > > > What's your Pi4 config.txt file look like? The GIC is not being handled > > > > correctly, and I'm guessing that configuration is wrong. You can't use > > > > the stock config.txt file with Xen, you have to modify the > > > > configuration a > > > > bit. > > > > > > Understood. I'm actually using a custom one: > > > https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/config.txt > > > > > > I could swear that I had a GIC setting in it -- but apparently no -- so > > > I added the following at the top of what you could see at the URL above: > > > > > > total_mem=4096 > > > enable_gic=1 > > > > > > > I think just adding: > > > > > > > > enable_gic=1 > > > > total_mem=1024 > > > > > > Right -- but my board has 4G memory -- so I think what I did above should > > > work. > > > > Nope. If you say 4096M of RAM, y
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Sat, May 02, 2020 at 06:48:27PM +0100, Julien Grall wrote: > > > On 02/05/2020 18:35, Corey Minyard wrote: > > On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote: > > No. If I am understanding this correctly, all the memory in dom0 below > > 1GB would have to be physically below 1GB. > > Well, dom0 is directly mapped. In other word, dom0 physical address == host > physical address. So if we allocate memory below 1GB in Xen, then it will > mapped below 1GB on dom0 as well. > > The patch I suggested would try to allocate as much as possible memory below > 1GB. I believe this should do the trick for you here. Yes, that does seem to do the trick: root@raspberrypi4-64-xen:~# xl info host : raspberrypi4-64-xen release: 4.19.115-v8 version: #1 SMP PREEMPT Thu Apr 16 13:53:57 UTC 2020 machine: aarch64 nr_cpus: 4 max_cpu_id : 3 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz: 54.000 hw_caps: ::::::: virt_caps : hvm hap total_memory : 3956 free_memory: 3634 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 13 xen_extra : .0 xen_version: 4.13.0 xen_caps : xen-3.0-aarch64 xen-3.0-armv7l xen_scheduler : credit2 xen_pagesize : 4096 platform_params: virt_start=0x20 xen_changeset : Tue Dec 17 14:19:49 2019 + git:a2e84d8e42-dirty xen_commandline: console=dtuart dtuart=/soc/serial@7e215040 sync_console dom0_mem=256M bootscrub=0 cc_compiler: aarch64-montavista-linux-gcc (GCC) 9.3.0 cc_compile_by : xen-4.13+gitAUT cc_compile_domain : mvista-cgx cc_compile_date: 2019-12-17 build_id : b0e9b4af9d83f67953e1640976f0720452a88f6a xend_config_format : 4 Thanks for the fix. -corey > > Cheers, > > -- > Julien Grall
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote: > Hi, > > On 02/05/2020 03:16, Corey Minyard wrote: > > On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote: > > > On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote: > > > > > > > > On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote: > > > > > Hi! > > > > > > > > > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock, > > > > > upstream kernel. The kernel itself works perfectly well > > > > > on the board. When I try booting it as Dom0 under Xen, > > > > > it goes into a stacktrace (attached). > > > > > > > > Getting Xen working on the Pi4 requires a lot of moving parts, and they > > > > all have to be right. > > > > > > Tell me about it! It is a pretty frustrating journey to align > > > everything just right. > > > On the other hand -- it seems worth to enable RPi as an ARM development > > > platform for Xen given how ubiquitous it is. > > > > > > Hence me trying to combine pristine upstream kernel (5.6.1) with > > > pristine upstream > > > Xen to enable 100% upstream developer workflow on RPi. > > > > > > > > Looking at what nice folks over at Dornerworks have previously > > > > > done to make RPi kernels boot as Dom0 I've come across these > > > > > 3 patches: > > > > > > > > > > https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux > > > > > > > > > > The first patch seems irrelevant (unless I'm missing something > > > > > really basic here). > > > > > > > > It might be irrelevant for your configuration, assuming that Xen gets > > > > the right information from EFI. I haven't tried EFI booting. > > > > > > I'd doing a bit of belt-and-suspenders strategy really -- I'm actually > > > using UEFI u-boot implementation that pre-populates device trees > > > and then I'm also forcing an extra copy of it to be load explicitly > > > via the GRUB devicetree command (GRUB runs as a UEFI payload). > > > > > > I also have access to the semi-official TianoCore RPi4 port that seems > > > to be working pretty well: https://github.com/pftf/RPi4/releases/tag/v1.5 > > > for booting all sort of UEFI payloads on RPi4. > > > > > > > > The 2nd patch applied with no issue (but > > > > > I don't think it is related) but the 3d patch failed to apply on > > > > > account of 5.6.1 kernel no longer having: > > > > > dev->archdata.dev_dma_ops > > > > > E.g. > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55 > > > > > > > > > > I've tried to emulate the effect of the patch by simply introducing > > > > > a static variable that would signal that we already initialized > > > > > dev->dma_ops -- but that didn't help at all. > > > > > > > > > > I'm CCing Jeff Kubascik to see if the original authors of that Corey > > > > > Minyard > > > > > to see if may be they have any suggestions on how this may be dealt > > > > > with. > > > > > > > > > > Any advice would be greatly appreciated! > > > > > > > > What's your Pi4 config.txt file look like? The GIC is not being handled > > > > correctly, and I'm guessing that configuration is wrong. You can't use > > > > the stock config.txt file with Xen, you have to modify the > > > > configuration a > > > > bit. > > > > > > Understood. I'm actually using a custom one: > > > https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/config.txt > > > > > > I could swear that I had a GIC setting in it -- but apparently no -- so > > > I added the following at the top of what you could see at the URL above: > > > > > > total_mem=4096 > > > enable_gic=1 > > > > > > > I think just adding: > > > > > > > > enable_gic=1 > > > > total_mem=1024 > > > > > > Right -- but my board has 4G memory -- so I think what I did above should > > > work. > > > > Nope. If you say 4096M of RAM, yo
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote: > On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote: > > > > On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote: > > > Hi! > > > > > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock, > > > upstream kernel. The kernel itself works perfectly well > > > on the board. When I try booting it as Dom0 under Xen, > > > it goes into a stacktrace (attached). > > > > Getting Xen working on the Pi4 requires a lot of moving parts, and they > > all have to be right. > > Tell me about it! It is a pretty frustrating journey to align > everything just right. > On the other hand -- it seems worth to enable RPi as an ARM development > platform for Xen given how ubiquitous it is. > > Hence me trying to combine pristine upstream kernel (5.6.1) with > pristine upstream > Xen to enable 100% upstream developer workflow on RPi. > > > > Looking at what nice folks over at Dornerworks have previously > > > done to make RPi kernels boot as Dom0 I've come across these > > > 3 patches: > > > > > > https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux > > > > > > The first patch seems irrelevant (unless I'm missing something > > > really basic here). > > > > It might be irrelevant for your configuration, assuming that Xen gets > > the right information from EFI. I haven't tried EFI booting. > > I'd doing a bit of belt-and-suspenders strategy really -- I'm actually > using UEFI u-boot implementation that pre-populates device trees > and then I'm also forcing an extra copy of it to be load explicitly > via the GRUB devicetree command (GRUB runs as a UEFI payload). > > I also have access to the semi-official TianoCore RPi4 port that seems > to be working pretty well: https://github.com/pftf/RPi4/releases/tag/v1.5 > for booting all sort of UEFI payloads on RPi4. > > > > The 2nd patch applied with no issue (but > > > I don't think it is related) but the 3d patch failed to apply on > > > account of 5.6.1 kernel no longer having: > > > dev->archdata.dev_dma_ops > > > E.g. > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55 > > > > > > I've tried to emulate the effect of the patch by simply introducing > > > a static variable that would signal that we already initialized > > > dev->dma_ops -- but that didn't help at all. > > > > > > I'm CCing Jeff Kubascik to see if the original authors of that Corey > > > Minyard > > > to see if may be they have any suggestions on how this may be dealt > > > with. > > > > > > Any advice would be greatly appreciated! > > > > What's your Pi4 config.txt file look like? The GIC is not being handled > > correctly, and I'm guessing that configuration is wrong. You can't use > > the stock config.txt file with Xen, you have to modify the configuration a > > bit. > > Understood. I'm actually using a custom one: > https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/config.txt > > I could swear that I had a GIC setting in it -- but apparently no -- so > I added the following at the top of what you could see at the URL above: > > total_mem=4096 > enable_gic=1 > > > I think just adding: > > > > enable_gic=1 > > total_mem=1024 > > Right -- but my board has 4G memory -- so I think what I did above should > work. Nope. If you say 4096M of RAM, your issue is almost certainly DMA, but it's not (just) the Linux code. On the Raspberry Pi 4, several devices cannot DMA to above 1024M of RAM, but Xen does not handle this. The 1024M of RAM is a limitation you will have to live with until Xen has a fix. I know I saw a reference for this, but I can't find it now. I saw someone say it booted with 4G, but I was unable to get it to boot with without setting total_mem=1024. -corey > > > might get it working, or at least solve one problem. It's required either > > way. That might get rid of the GIC errors at the beginning. I see a > > few of those, but not that many. > > > > My kernel command line is: > > > > coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M > > smsc95xx.macaddr=DC:A6:32:4F:3A:CD vc_mem.mem_base=0x3ec0 > > vc_mem.mem_size=0x4000 console=hvc0 clk_ignore_unused > > root=/dev/mmcblk0p2 rootwait > > > > A lot of that configuration
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote: > Hi! > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock, > upstream kernel. The kernel itself works perfectly well > on the board. When I try booting it as Dom0 under Xen, > it goes into a stacktrace (attached). Getting Xen working on the Pi4 requires a lot of moving parts, and they all have to be right. > > Looking at what nice folks over at Dornerworks have previously > done to make RPi kernels boot as Dom0 I've come across these > 3 patches: > https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux > > The first patch seems irrelevant (unless I'm missing something > really basic here). It might be irrelevant for your configuration, assuming that Xen gets the right information from EFI. I haven't tried EFI booting. > The 2nd patch applied with no issue (but > I don't think it is related) but the 3d patch failed to apply on > account of 5.6.1 kernel no longer having: > dev->archdata.dev_dma_ops > E.g. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55 > > I've tried to emulate the effect of the patch by simply introducing > a static variable that would signal that we already initialized > dev->dma_ops -- but that didn't help at all. > > I'm CCing Jeff Kubascik to see if the original authors of that Corey Minyard > to see if may be they have any suggestions on how this may be dealt > with. > > Any advice would be greatly appreciated! What's your Pi4 config.txt file look like? The GIC is not being handled correctly, and I'm guessing that configuration is wrong. You can't use the stock config.txt file with Xen, you have to modify the configuration a bit. I think just adding: enable_gic=1 total_mem=1024 might get it working, or at least solve one problem. It's required either way. That might get rid of the GIC errors at the beginning. I see a few of those, but not that many. My kernel command line is: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M smsc95xx.macaddr=DC:A6:32:4F:3A:CD vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=hvc0 clk_ignore_unused root=/dev/mmcblk0p2 rootwait A lot of that configuration gets pulled from the initialization done by the GPU at startup which it put into the device tree. I'm not sure what a lot of it means. Some of it is added by Xen, too. I can verify the DMA patch is important. I'm not sure how to apply it to a 5.6 kernel, though. Keep us informed when you get it working. -corey > > Thanks, > Roman. > grub> xen_hypervisor (hd0,gpt1)/xen dom0_mem=1024M,max:1024M dom0_max_vcpus=1 > grub> xen_module (hd0,gpt1)/kernel console=hvc0 earlyprintk=xen nomodeset > grub> devicetree (hd0,gpt1)/bcm2711-rpi-4-b.dtb > grub> boot > Using modules provided by bootloader in FDT > Xen 4.13.0 (c/s Tue Dec 17 14:19:49 2019 + git:a2e84d8e42-dirty) EFI > loader > Warning: Could not query variable store: 0x8003 > - UART enabled - > - Boot CPU booting - > - Current EL 0008 - > - Initialize CPU - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 1000 - 07ef1fff > (XEN) RAM: 07ef2000 - 07f0dfff > (XEN) RAM: 07f0e000 - 2bc4dfff > (XEN) RAM: 3cb1 - 3cb10fff > (XEN) RAM: 3cb12000 - 3cb13fff > (XEN) RAM: 3cb1b000 - 3cb1cfff > (XEN) RAM: 4000 - fbff > (XEN) > (XEN) MODULE[0]: 2bc5d000 - 2bd978f0 Xen > (XEN) MODULE[1]: 2bc4f000 - 2bc5d000 Device Tree > (XEN) MODULE[2]: 2bda5000 - 2d684200 Kernel > (XEN) > (XEN) CMDLINE[2bda5000]:chosen console=hvc0 earlyprintk=xen nomodeset > (XEN) > (XEN) Command line: dom0_mem=1024M,max:1024M dom0_max_vcpus=1 > (XEN) parameter "dom0_mem" has invalid value "1024M,max:1024M", rc=-22! > (XEN) Domain heap initialised > (XEN) Booting using Device Tree > (XEN) Platform: Raspberry Pi 4 > (XEN) No dtuart path configured > (XEN) Bad console= option 'dtuart' > Xen 4.13.0 > (XEN) Xen version 4.13.0 (@) (aarch64-linux-gnu-gcc (Ubuntu 9.3.0-10ubuntu2) > 9.3.0) debug=y Thu Apr 30 17:06:40 PDT 2020 > (XEN) Latest ChangeSet: Tue Dec 17 14:19:49 2019 + git:a2e84d8e42-dirty > (XEN) build-id: 7efa3c5cb27a98e9eb2e750fa71c8a065b9b5cb6 > (XEN) Processor: 410fd083: "ARM Limited", variant: 0x0, part 0xd08, rev 0x3 > (XEN) 64-bit Execution: > (XEN) Processor Features: > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32
Re: [PATCH-for-5.1 2/3] various: Remove unnecessary OBJECT() cast
On Sun, Apr 12, 2020 at 11:09:53PM +0200, Philippe Mathieu-Daudé wrote:
> The OBJECT() macro is defined as:
>
> #define OBJECT(obj) ((Object *)(obj))
>
> Remove unnecessary OBJECT() casts.
For ipmi change:
Acked-by: Corey Minyard
>
> Patch created mechanically using spatch with this script:
>
> @@
> typedef Object;
> Object *o;
> @@
> - OBJECT(o)
> + o
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/core/bus.c | 2 +-
> hw/ide/ahci-allwinner.c | 2 +-
> hw/ipmi/smbus_ipmi.c| 2 +-
> hw/microblaze/petalogix_ml605_mmu.c | 8
> hw/s390x/sclp.c | 2 +-
> monitor/misc.c | 3 +--
> qom/object.c| 4 ++--
> 7 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/hw/core/bus.c b/hw/core/bus.c
> index 3dc0a825f0..4ea5870de8 100644
> --- a/hw/core/bus.c
> +++ b/hw/core/bus.c
> @@ -25,7 +25,7 @@
>
> void qbus_set_hotplug_handler(BusState *bus, Object *handler, Error **errp)
> {
> -object_property_set_link(OBJECT(bus), OBJECT(handler),
> +object_property_set_link(OBJECT(bus), handler,
> QDEV_HOTPLUG_HANDLER_PROPERTY, errp);
> }
>
> diff --git a/hw/ide/ahci-allwinner.c b/hw/ide/ahci-allwinner.c
> index bb8393d2b6..8536b9eb5a 100644
> --- a/hw/ide/ahci-allwinner.c
> +++ b/hw/ide/ahci-allwinner.c
> @@ -90,7 +90,7 @@ static void allwinner_ahci_init(Object *obj)
> SysbusAHCIState *s = SYSBUS_AHCI(obj);
> AllwinnerAHCIState *a = ALLWINNER_AHCI(obj);
>
> -memory_region_init_io(&a->mmio, OBJECT(obj), &allwinner_ahci_mem_ops, a,
> +memory_region_init_io(&a->mmio, obj, &allwinner_ahci_mem_ops, a,
>"allwinner-ahci", ALLWINNER_AHCI_MMIO_SIZE);
> memory_region_add_subregion(&s->ahci.mem, ALLWINNER_AHCI_MMIO_OFF,
> &a->mmio);
> diff --git a/hw/ipmi/smbus_ipmi.c b/hw/ipmi/smbus_ipmi.c
> index 2a9470d9df..f1a0148755 100644
> --- a/hw/ipmi/smbus_ipmi.c
> +++ b/hw/ipmi/smbus_ipmi.c
> @@ -329,7 +329,7 @@ static void smbus_ipmi_init(Object *obj)
> {
> SMBusIPMIDevice *sid = SMBUS_IPMI(obj);
>
> -ipmi_bmc_find_and_link(OBJECT(obj), (Object **) &sid->bmc);
> +ipmi_bmc_find_and_link(obj, (Object **) &sid->bmc);
> }
>
> static void smbus_ipmi_get_fwinfo(struct IPMIInterface *ii, IPMIFwInfo *info)
> diff --git a/hw/microblaze/petalogix_ml605_mmu.c
> b/hw/microblaze/petalogix_ml605_mmu.c
> index 0a2640c40b..52dcea9abd 100644
> --- a/hw/microblaze/petalogix_ml605_mmu.c
> +++ b/hw/microblaze/petalogix_ml605_mmu.c
> @@ -150,9 +150,9 @@ petalogix_ml605_init(MachineState *machine)
> qdev_set_nic_properties(eth0, &nd_table[0]);
> qdev_prop_set_uint32(eth0, "rxmem", 0x1000);
> qdev_prop_set_uint32(eth0, "txmem", 0x1000);
> -object_property_set_link(OBJECT(eth0), OBJECT(ds),
> +object_property_set_link(OBJECT(eth0), ds,
> "axistream-connected", &error_abort);
> -object_property_set_link(OBJECT(eth0), OBJECT(cs),
> +object_property_set_link(OBJECT(eth0), cs,
> "axistream-control-connected", &error_abort);
> qdev_init_nofail(eth0);
> sysbus_mmio_map(SYS_BUS_DEVICE(eth0), 0, AXIENET_BASEADDR);
> @@ -163,9 +163,9 @@ petalogix_ml605_init(MachineState *machine)
> cs = object_property_get_link(OBJECT(eth0),
>"axistream-control-connected-target",
> NULL);
> qdev_prop_set_uint32(dma, "freqhz", 100 * 100);
> -object_property_set_link(OBJECT(dma), OBJECT(ds),
> +object_property_set_link(OBJECT(dma), ds,
> "axistream-connected", &error_abort);
> -object_property_set_link(OBJECT(dma), OBJECT(cs),
> +object_property_set_link(OBJECT(dma), cs,
> "axistream-control-connected", &error_abort);
> qdev_init_nofail(dma);
> sysbus_mmio_map(SYS_BUS_DEVICE(dma), 0, AXIDMA_BASEADDR);
> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
> index f0c35aa57a..bae9d2350f 100644
> --- a/hw/s390x/sclp.c
> +++ b/hw/s390x/sclp.c
> @@ -288,7 +288,7 @@ void s390_sclp_init(void)
>
> object_property_add_child(qdev_get_machine(), TYPE_SCLP, new,
>NULL);
> -object_unref(OBJECT(new));
> +object_unref(new);
> qdev_init_nofail(DEVICE(new));
> }
>
> diff --git a/monitor/misc.c b/monitor/misc.c
> index 6c45fa49
Re: [Xen-devel] [PATCH v3 23/25] hw/ipmi: Assert outlen > outpos
On Wed, Feb 20, 2019 at 02:02:30AM +0100, Philippe Mathieu-Daudé wrote:
> A througfull audit show that all time data is added to outbuf[],
> 'outlen' is incremented. Then at creation and each time
> continue_send() returns it pass thru check_reset which resets
> 'outpos', thus we always have 'outlen >= outpos'.
Perhaps: "A thorough audit shows that outlen is always incremented
when data is always added to outbuf[]. Then at creation and each
time continus_send() returns it assures if outpos reaches outlen,
both values are reset to zero, except in the case of sending
a reset where a new command is added."
This is certainly the design intent, thank you for the thorough
audit.
> Also due to the check on entry, we know outlen != 0.
> We can then add an assertion on 'outlen > outpos', which will
> helps the next patch to safely convert 'outlen - outpos' as an
I was a little confused by "next patch", there is no following
patch in the series for this. Maybe "next part of the patch"?
> unsigned type (size_t).
>
> Make this assertion explicit by casting 'outlen - outpos' size_t.
>
> Signed-off-by: Philippe Mathieu-Daudé
Outside of the minor grammer issues, this looks good. I have
noticed the inconsistent signed/unsigned usage in qemu and IMHO
it's likely to lead to very bad bugs at some point. There have
been studies that show that unsigned values tend to be more
buggy in usage due to underflows, but for a length value that
will eventually be converted to an unsigned value, what is
here is better, I think.
Both outpos and outlen are unsigned, so the size_t() cast is
not really necessary, but I guess it makes it clear.
Reviewed-by: Corey Minyard
> ---
> hw/ipmi/ipmi_bmc_extern.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/ipmi/ipmi_bmc_extern.c b/hw/ipmi/ipmi_bmc_extern.c
> index bf0b7ee0f5..ca61b04942 100644
> --- a/hw/ipmi/ipmi_bmc_extern.c
> +++ b/hw/ipmi/ipmi_bmc_extern.c
> @@ -107,8 +107,9 @@ static void continue_send(IPMIBmcExtern *ibe)
> goto check_reset;
> }
> send:
> +assert(ibe->outlen > ibe->outpos);
> ret = qemu_chr_fe_write(&ibe->chr, ibe->outbuf + ibe->outpos,
> -ibe->outlen - ibe->outpos);
> +(size_t)(ibe->outlen - ibe->outpos));
> if (ret > 0) {
> ibe->outpos += ret;
> }
> --
> 2.20.1
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
