On 25.08.2022 20:09, Stefano Stabellini wrote:
> But first, let's confirm whether this change:
>
>
> #define dt_for_each_property_node(dn, pp) \
> -for ( pp = dn->properties; pp != NULL; pp = pp->next )
> +for ( pp = (dn)->properties; pp != NULL; pp = (pp)->next )
>
>
flight 172782 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172776 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172774 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
flight 172780 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172772 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172772/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
This is needed for fwupd to work in Qubes OS.
Signed-off-by: Demi Marie Obenour
---
drivers/firmware/efi/esrt.c | 34 --
drivers/xen/efi.c | 33 +
include/linux/efi.h | 10 ++
3 files changed, 67 insertions
flight 172777 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
> On 24.08.2022 23:04, Demi Marie Obenour wrote:
> > The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
> > only sets info->mem.size if the initial value was *larger* than the size
> > of the memory region.
>
> And inte
flight 172768 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172775 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172775/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6 lib
CC MISRA C working group
Short summary: we are discussing whether the following is sufficient to
address MISRA C Rule 20.7, and also in general for safety:
#define dt_for_each_property_node(dn, pp) \
-for ( pp = dn->properties; pp != NULL; pp = pp->next )
+for ( pp = (
On Thu, 25 Aug 2022, Bertrand Marquis wrote:
> > On 25 Aug 2022, at 10:37, Julien Grall wrote:
> > On 25/08/2022 08:39, Bertrand Marquis wrote:
> >> Hi,
> >>> On 25 Aug 2022, at 02:10, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Wed, 24 Aug 2022, Julien Grall wrote:
> On 24/08/2022 22:5
flight 172773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-amd64-xsm 4 host-install(4)
flight 172766 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
Hi Juergen,
Thank you for the quick and nice reply!
On Thu, 25 Aug 2022 08:20:33 +0200 Juergen Gross wrote:
>
[...]
>
> Could you please send it as two proper patches (one for each driver) with
> the correct "Fixes:" tags?
Sure, just posted:
https://lore.kernel.org/xen-devel/20220825161511.
Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter
when connect") made blkback to advertise its support of the persistent
grants feature only if the user sets the 'feature_persistent' parameter
of the driver and the frontend advertised its support of the feature.
However, follo
Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter
when connect") made blkback to advertise its support of the persistent
grants feature only if the user sets the 'feature_persistent' parameter
of the driver and the frontend advertised its support of the feature.
However, follo
Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter
when connect") made blkback to advertise its support of the persistent
grants feature only if the user sets the 'feature_persistent' parameter
of the driver and the frontend advertised its support of the feature.
However, follo
On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote:
> The important part is to include those buffers in IOMMU page table
> relevant for the USB controller. Otherwise, DbC will stop working as
> soon as IOMMU is enabled, regardless of to which domain device assigned
> (be it xen or dom0).
> If th
On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote:
> Add API similar to rmrr= and ivmd= arguments, but in a common code. This
> will allow drivers to register reserved memory regardless of the IOMMU
> vendor.
> The direct reason for this API is xhci-dbc console driver (aka xue),
> that needs to
On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote:
> This allows configuring EHCI and XHCI consoles separately,
> simultaneously.
>
> Suggested-by: Jan Beulich
But was I maybe confused, and much less of a change would suffice? After
all ...
> --- a/xen/drivers/char/xhci-dbc.c
> +++ b/xen/dr
On 25.08.2022 13:10, Dylanger Daly wrote:
> Yes please, I have Qubes's Build System setup with sourcehut so I can add
> patches at will, however please be aware Qubes currently uses Xen 4.14.
>
> I'll take a look and see if I can access that location
>
> With the added logging I should be able t
Hi Julien,
On Thu, Aug 25, 2022 at 01:59:06PM +0100, Julien Grall wrote:
[...]
> > Seems to me, to support para virtualization driver model (like virtio),
> > Dom0 needs to provide the device driver backend, and DomUs enables
> > the forend device drivers. In this case, the most hardware interr
On 25.08.2022 16:19, Juergen Gross wrote:
> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
> potentially with pages being NULL, leading to a NULL dereference.
>
> Additionally lock_pages() doesn't check for pin_user_pages_fast()
> having been completely successful, resulting in
Hi Jan,
On 25/08/2022 15:34, Jan Beulich wrote:
On 25.08.2022 16:31, Julien Grall wrote:
On 24/08/2022 13:44, Bertrand Marquis wrote:
On 24 Aug 2022, at 13:33, Jan Beulich wrote:
While Arm64 does so uniformly, for Arm32 only strchr() currently handles
this properly. Add the necessary convers
On 25.08.2022 16:31, Julien Grall wrote:
> On 24/08/2022 13:44, Bertrand Marquis wrote:
>>> On 24 Aug 2022, at 13:33, Jan Beulich wrote:
>>>
>>> While Arm64 does so uniformly, for Arm32 only strchr() currently handles
>>> this properly. Add the necessary conversion also to strrchr(), memchr(),
>>>
flight 172764 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
On 24/08/2022 13:44, Bertrand Marquis wrote:
On 24 Aug 2022, at 13:33, Jan Beulich wrote:
While Arm64 does so uniformly, for Arm32 only strchr() currently handles
this properly. Add the necessary conversion also to strrchr(), memchr(),
and memset().
As to the placement in memset(): Putting
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This
flight 172771 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 22.08.2022 04:58, Wei Chen wrote:
> Current NUMA nodes number is a hardcode configuration. This
> configuration is difficult for an administrator to change
> unless changing the code.
>
> So in this patch, we introduce this new Kconfig option for
> administrators to change NUMA nodes number con
Hi Leo,
On 25/08/2022 12:50, Leo Yan wrote:
On Thu, Aug 25, 2022 at 10:07:18AM +0100, Julien Grall wrote:
[...]
Xen directly passes ACPI MADT table from UEFI to Linux kernel to Dom0,
(see functions acpi_create_madt() and gic_make_hwdom_madt()), which
means the Linux kernel Dom0 uses the same
Hi Leo,
On 25/08/2022 12:24, Leo Yan wrote:
On Thu, Aug 25, 2022 at 10:07:18AM +0100, Julien Grall wrote:
[...]
In other words, let's assume the Dom0 kernel panic and its secondary
kernel is launched by kexec, is it necessarily for the secondary
kernel to reuse the primary kernel's RD pending
On 22.08.2022 04:58, Wei Chen wrote:
> --- a/xen/common/numa.c
> +++ b/xen/common/numa.c
> @@ -13,6 +13,21 @@
> #include
> #include
>
> +static nodemask_t __initdata processor_nodes_parsed;
> +static nodemask_t __initdata memory_nodes_parsed;
> +static struct node __initdata nodes[MAX_NUMNODE
flight 172765 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 25.08.2022 14:10, Juergen Gross wrote:
> On 25.08.22 13:58, Jan Beulich wrote:
>> On 25.08.2022 13:40, Juergen Gross wrote:
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -581,7 +581,7 @@ static int lock_pages(
>>> struct privcmd_dm_op_buf kbufs[], unsigned int num,
>
On 22.08.2022 04:58, Wei Chen wrote:
> @@ -96,3 +97,27 @@ unsigned int __init arch_get_dma_bitsize(void)
> flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 -
> 1)
> + PAGE_SHIFT, 32);
> }
> +
> +/*
> + * This function provides the ability for caller to
On 25.08.22 13:42, Borislav Petkov wrote:
On Thu, Aug 25, 2022 at 12:41:05PM +0200, Juergen Gross wrote:
Maybe the alternative reasoning is much faster to understand: if the
Cyrix set_all() could be called, the AMD and Centaur ones would be callable,
too.
Right.
Those being called would resu
On 25.08.22 13:58, Jan Beulich wrote:
On 25.08.2022 13:40, Juergen Gross wrote:
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -581,7 +581,7 @@ static int lock_pages(
struct privcmd_dm_op_buf kbufs[], unsigned int num,
struct page *pages[], unsigned int nr_pages, unsi
flight 172762 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172762/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 172754
Tests which did not succeed
On Wed, Aug 24, 2022 at 03:52:27PM +0200, Juergen Gross wrote:
> On 24.08.22 14:10, Greg Kroah-Hartman wrote:
> > On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> > > Hi Greg,
> > >
> > > stable kernels 5.18 and 5.15 seem to be missing upstream patch
> > > c64cc2802a78 ("x86/entry:
On 25.08.2022 13:40, Juergen Gross wrote:
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -581,7 +581,7 @@ static int lock_pages(
> struct privcmd_dm_op_buf kbufs[], unsigned int num,
> struct page *pages[], unsigned int nr_pages, unsigned int *pinned)
> {
> - unsi
On Thu, Aug 25, 2022 at 10:07:18AM +0100, Julien Grall wrote:
[...]
> > Xen directly passes ACPI MADT table from UEFI to Linux kernel to Dom0,
> > (see functions acpi_create_madt() and gic_make_hwdom_madt()), which
> > means the Linux kernel Dom0 uses the same ACPI table to initialize GICv3
> > d
On Thu, Aug 25, 2022 at 12:41:05PM +0200, Juergen Gross wrote:
> Maybe the alternative reasoning is much faster to understand: if the
> Cyrix set_all() could be called, the AMD and Centaur ones would be callable,
> too.
Right.
> Those being called would result in a NULL deref, so why should we ke
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This
Hi Julien,
On Thu, Aug 25, 2022 at 10:07:18AM +0100, Julien Grall wrote:
[...]
> > In other words, let's assume the Dom0 kernel panic and its secondary
> > kernel is launched by kexec, is it necessarily for the secondary
> > kernel to reuse the primary kernel's RD pending page?
>
> No.
If the
Hi Henry,
On 24/08/2022 09:31, Henry Wang wrote:
>
> This commit firstly adds a global variable `reserved_heap`.
> This newly introduced global variable is set at the device tree
> parsing time if the reserved heap ranges are defined in the device
> tree chosen node.
>
Did you consider putting r
On 25.08.22 12:22, Jan Beulich wrote:
On 25.08.2022 12:13, Juergen Gross wrote:
On 25.08.22 11:50, Jan Beulich wrote:
On 25.08.2022 11:26, Juergen Gross wrote:
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -602,6 +602,10 @@ static int lock_pages(
*pinned += page_co
Hi Jan,
Yes please, I have Qubes's Build System setup with sourcehut so I can add
patches at will, however please be aware Qubes currently uses Xen 4.14.
I'll take a look and see if I can access that location
With the added logging I should be able to trigger the crash and get to the
bottom of
On 22.08.2022 04:58, Wei Chen wrote:
> --- /dev/null
> +++ b/xen/common/numa.c
> @@ -0,0 +1,440 @@
> +/*
> + * Generic VM initialization for NUMA setups.
> + * Copyright 2002,2003 Andi Kleen, SuSE Labs.
> + * Adapted for Xen: Ryan Harper
> + */
> +
> +#include
> +#include
> +#include
> +#includ
flight 172769 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 25.08.22 12:31, Borislav Petkov wrote:
On Sat, Aug 20, 2022 at 11:25:25AM +0200, Juergen Gross wrote:
The Cyrix cpu specific MTRR function cyrix_set_all() will never be
called, as the struct mtrr_ops set_all() callback will only be called
in the use_intel() case, which would require the use_i
On 25.08.22 12:31, Borislav Petkov wrote:
On Sat, Aug 20, 2022 at 11:25:25AM +0200, Juergen Gross wrote:
The Cyrix cpu specific MTRR function cyrix_set_all() will never be
called, as the struct mtrr_ops set_all() callback will only be called
in the use_intel() case, which would require the use_i
On 25.08.2022 12:13, Juergen Gross wrote:
> On 25.08.22 11:50, Jan Beulich wrote:
>> On 25.08.2022 11:26, Juergen Gross wrote:
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -602,6 +602,10 @@ static int lock_pages(
>>> *pinned += page_count;
>>> nr_pa
On 22.08.2022 04:58, Wei Chen wrote:
> --- a/xen/arch/x86/include/asm/numa.h
> +++ b/xen/arch/x86/include/asm/numa.h
> @@ -32,8 +32,9 @@ extern void numa_add_cpu(int cpu);
> extern void numa_init_array(void);
> extern bool numa_off;
>
> -
> -extern int srat_disabled(void);
> +extern int arch_nu
On 25.08.22 11:50, Jan Beulich wrote:
On 25.08.2022 11:26, Juergen Gross wrote:
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been compl
On 25.08.2022 11:48, Bertrand Marquis wrote:
> When Xen is compiled for x86 on an arm machine, libacpi build is failing
> due to a wrong include path:
> - arch-x86/xen.h includes xen.h
> - xen.h includes arch-arm.h (as __i386__ and __x86_64__ are not defined
> but arm ones are).
>
> To solve this
On 25.08.2022 11:26, Juergen Gross wrote:
> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
> potentially with pages being NULL, leading to a NULL dereference.
>
> Additionally lock_pages() doesn't check for pin_user_pages_fast()
> having been completely successful, resulting in
When Xen is compiled for x86 on an arm machine, libacpi build is failing
due to a wrong include path:
- arch-x86/xen.h includes xen.h
- xen.h includes arch-arm.h (as __i386__ and __x86_64__ are not defined
but arm ones are).
To solve this issue move XEN_ACPI_ definitions in a new header
guest-acpi
Hi Julien,
> On 25 Aug 2022, at 10:37, Julien Grall wrote:
>
>
>
> On 25/08/2022 08:39, Bertrand Marquis wrote:
>> Hi,
>>> On 25 Aug 2022, at 02:10, Stefano Stabellini wrote:
>>>
>>> On Wed, 24 Aug 2022, Julien Grall wrote:
On 24/08/2022 22:59, Stefano Stabellini wrote:
> On Wed, 24
On 25/08/2022 08:39, Bertrand Marquis wrote:
Hi,
On 25 Aug 2022, at 02:10, Stefano Stabellini wrote:
On Wed, 24 Aug 2022, Julien Grall wrote:
On 24/08/2022 22:59, Stefano Stabellini wrote:
On Wed, 24 Aug 2022, Rahul Singh wrote:
On 24 Aug 2022, at 4:36 pm, Julien Grall wrote:
On 24/08/
Hi Vipul,
> On 25 Aug 2022, at 09:56, Vipul Suneja wrote:
>
> Hi Bertrand,
>
> Thanks!
>
> No, I couldn't see /dev/loop0. Can you please guide me to create it?
First thing to try is “modprobe loop"
It that does not work (ie module not found) you should check in your linux
config if BLK_DEV_
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This
Hi,
On 25/08/2022 08:59, Leo Yan wrote:
On Fri, Aug 19, 2022 at 01:10:10PM +0100, Marc Zyngier wrote:
[...]
In the context of Xen, dom0 doesn't have direct access to the host ITS
because we are emulating it. So I think it doesn't matter for us because we
can fix our implementation if it is af
Hi Bertrand,
Thanks!
No, I couldn't see /dev/loop0. Can you please guide me to create it?
I didn't change dom0 configurations, it's default generated by yocto.
I will append this "IMAGE_FSTYPES:append = " wic.gz”" in local.conf & will
update you.
Regards,
Vipul Kumar
On Thu, Aug 25, 2022 at 1
On 24.08.2022 20:15, Dylanger Daly wrote:
> I'm sorry I didn't get where in /sys/firmware you'd like to take a look at.
It's been a long time since I last needed to access that, when it
was still /proc/mem and/or /proc/kmem. Their modern equivalents might
be /sys/devices/virtual/mem/{,k}mem ... Bu
On 25.08.2022 10:02, Xenia Ragiadakou wrote:
> On 8/22/22 14:48, Jan Beulich wrote:
>> On 22.08.2022 12:43, Xenia Ragiadakou wrote:
>>> On 8/22/22 12:59, Jan Beulich wrote:
On 19.08.2022 21:43, Xenia Ragiadakou wrote:
> In macros dt_for_each_property_node(), dt_for_each_device_node() and
>
On 24.08.2022 12:59, Andrew Cooper wrote:
> The IO port, MSR, IO-APIC and LAPIC accessors compile typically to single or
> pairs of instructions, which is less overhead than even the stack manipulation
> to call the helpers.
>
> Move the implementations from util.c to being static inlines in util.
On 25.08.22 09:38, Jan Beulich wrote:
On 24.08.2022 16:26, Juergen Gross wrote:
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Fix that by calling unlock_pages only if lock_pages() was at least
partially succes
On 24.08.2022 12:59, Andrew Cooper wrote:
> Since c/s 73b13705af7c ("firmware: provide a stand alone set of headers"),
> we've had an implementation of offsetof() which isn't undefined behaviour.
> Actually use it.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 8/22/22 14:48, Jan Beulich wrote:
On 22.08.2022 12:43, Xenia Ragiadakou wrote:
On 8/22/22 12:59, Jan Beulich wrote:
On 19.08.2022 21:43, Xenia Ragiadakou wrote:
In macros dt_for_each_property_node(), dt_for_each_device_node() and
dt_for_each_child_node(), add parentheses around the macro
On 24.08.2022 23:04, Demi Marie Obenour wrote:
> The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
> only sets info->mem.size if the initial value was *larger* than the size
> of the memory region.
And intentionally so - the caller didn't ask for any bigger region,
after all.
>
On Fri, Aug 19, 2022 at 01:10:10PM +0100, Marc Zyngier wrote:
[...]
> > > > In the context of Xen, dom0 doesn't have direct access to the host ITS
> > > > because we are emulating it. So I think it doesn't matter for us
> > > > because we
> > > > can fix our implementation if it is affected.
> >
flight 172767 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi Jan,
> On 25 Aug 2022, at 08:47, Jan Beulich wrote:
>
> On 24.08.2022 17:29, Bertrand Marquis wrote:
>> When Xen is compiled for x86 on an arm machine, libacpi build is failing
>> due to a wrong include path:
>> - arch-x86/xen.h includes xen.h
>> - xen.h includes arch-arm.h (as __i386__ and _
Hi Vipul,
> On 25 Aug 2022, at 08:31, Vipul Suneja wrote:
>
> Hi Stefano,
>
> Thanks!
>
> As suggested, I changed the guest1.cfg file. Below are the contents of config
> file
>
> kernel = "/home/root/Image"
> cmdline = "console=hvc0 earlyprintk=xen sync_console root=/dev/xvda"
> memory = "10
On 24.08.2022 17:29, Bertrand Marquis wrote:
> When Xen is compiled for x86 on an arm machine, libacpi build is failing
> due to a wrong include path:
> - arch-x86/xen.h includes xen.h
> - xen.h includes arch-arm.h (as __i386__ and __x86_64__ are not defined
> but arm ones are).
>
> To solve this
Hi,
> On 25 Aug 2022, at 02:10, Stefano Stabellini wrote:
>
> On Wed, 24 Aug 2022, Julien Grall wrote:
>> On 24/08/2022 22:59, Stefano Stabellini wrote:
>>> On Wed, 24 Aug 2022, Rahul Singh wrote:
> On 24 Aug 2022, at 4:36 pm, Julien Grall wrote:
> On 24/08/2022 15:42, Rahul Singh wrote
On 24.08.2022 16:26, Juergen Gross wrote:
> The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
> potentially with pages being NULL, leading to a NULL dereference.
>
> Fix that by calling unlock_pages only if lock_pages() was at least
> partially successful.
>
> Cc:
> Fixes: ab520b
Hi Stefano,
Thanks!
As suggested, I changed the guest1.cfg file. Below are the contents of
config file
*kernel = "/home/root/Image"cmdline = "console=hvc0 earlyprintk=xen
sync_console root=/dev/xvda"memory = "1024"name = "guest1"vcpus =
1serial="pty"disk = [
'file:/home/root/xen-guest-ima
On 24.08.2022 12:59, Andrew Cooper wrote:
> HVMLoader is not relocatable in memory, and 32bit PIC code has a large
> overhead. Build it as non-relocatable.
>
> Bloat-o-meter reports a net:
> add/remove: 0/0 grow/shrink: 3/107 up/down: 14/-3370 (-3356)
>
> No functional change.
>
> Signed-off-
I haven't been able to find evidence of "-nopie" ever having been a
supported compiler option. The correct spelling is "-no-pie".
Furthermore like "-pie" this is an option which is solely passed to the
linker. The compiler only recognizes "-fpie" / "-fPIE" / "-fno-pie", and
it doesn't infer these o
flight 172758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
84 matches
Mail list logo
