Hi Luca,
> -Original Message-
> From: Luca Fancellu
> Subject: [PATCH v6 12/12] xen/changelog: Add SVE and "dom0" options to the
> changelog for Arm
>
> Arm now can use the "dom0=" Xen command line option and the support
> for guests running SVE instructions is added, put entries in the
On 23.04.2023 07:36, Henry Wang wrote:
>> -Original Message-
>> From: Jan Beulich
However, looking at the code below, don't you mean to have the array
pre-set to all NUMA_NO_DISTANCE?
>>>
>>> ...I am a bit puzzled about why pre-setting the array to all
>>> NUMA_NO_DISTANCE matter
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>
>
> handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
> parameters. Then frame numbers are obtained from addr and len by right
> shifting
> with PAGE_SHIFT. The page frame numbers are saved using unsigned long.
Ma
On 21.04.2023 16:13, Volodymyr Babchuk wrote:
>
> Hi Roger,
>
> Roger Pau Monné writes:
>
>> On Fri, Apr 21, 2023 at 11:00:23AM +, Volodymyr Babchuk wrote:
>>>
>>> Hello Roger,
>>>
>>> Roger Pau Monné writes:
>>>
On Mon, Apr 17, 2023 at 12:34:31PM +0200, Jan Beulich wrote:
> On 17
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 03/17] xen/arm: implement node distance helpers for
> Arm
>
> > Thanks for the explanation! I think I now understand :) Would this diff
> below
> > look good to you then? Appreciate your patience.
>
> Looks largel
flight 180389 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 180386 REGR. vs. 180382
Tests which are f
On 24.04.2023 01:33, osstest service owner wrote:
> flight 180384 linux-linus real [real]
> flight 180387 linux-linus real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/180384/
> http://logs.test-lab.xenproject.org/osstest/logs/180387/
>
> Regressions :-(
>
> Tests which did no
Hi,
On 19/04/2023 13:05, Michal Orzel wrote:
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigne
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>
>
> Restructure the code so that one can use pa_range_info[] table for both
> ARM_32 as well as ARM_64.
>
> Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
> p2m_root_order can be obtained from the pa_range_info[].ro
Hi,
On 21/04/2023 09:03, Michal Orzel wrote:
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_
This patch series aims to make the msr intercept handling, performed in
vpmu code, virtualization technology agnostic.
It creates a common interface for setting/clearing the msr intercepts and
then add hooks to the corresponding hvm_funcs table to be able to call the
svm/vmx specific handlers throu
This change aims to render the control interface of MSR intercepts identical
between SVM and VMX code, so that the control of the MSR intercept in common
code can be done through an hvm_funcs callback.
Create two new functions:
- svm_set_msr_intercept(), enables interception of read/write accesses
Add hvm_funcs hooks for {set,clear}_msr_intercept() for controlling the msr
intercept in common vpmu code.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- change the parameter types to unsigned int
xen/arch/x86/cpu/vpmu_amd.c | 10 -
x
Replace enum vmx_msr_intercept_type with the msr access flags, defined
in hvm.h, so that the functions {svm,vmx}_{set,clear}_msr_intercept()
share the same prototype.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
---
Changes in v2:
- change from int to unsigned int the type o
Hi,
On 13/04/2023 18:37, Ayan Kumar Halder wrote:
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The page frame numbers are saved using unsigned long.
Now if 64-bit >> PA
On 24/04/2023 08:44, Michal Orzel wrote:
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The page frame numbers
On 28.03.2023 16:43, Juergen Gross wrote:
> Today when finalizing a transaction the number of node quota is checked
> to not being exceeded after the transaction. This check is always done,
> even if the transaction is being performed by a privileged connection,
> or if there were no nodes created
On 21.04.2023 16:41, Oleksii wrote:
> On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
>> On 19.04.2023 17:42, Oleksii Kurochko wrote:
>>> + *
>>> ===
>>> =
>>> + * Start addr | End addr | Size | VM area
>
On 21.04.2023 16:41, Oleksii wrote:
> On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
>> On 19.04.2023 17:42, Oleksii Kurochko wrote:
>>> + *
>>> ===
>>> =
>>> + * Start addr | End addr | Size | VM area
>
On 24.04.23 10:56, Jan Beulich wrote:
On 28.03.2023 16:43, Juergen Gross wrote:
Today when finalizing a transaction the number of node quota is checked
to not being exceeded after the transaction. This check is always done,
even if the transaction is being performed by a privileged connection,
o
flight 180390 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180390/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken
test-amd64-amd64-dom0pvh-xl-intel 27
On 21.04.2023 18:01, Oleksii wrote:
> On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich wrote:
>> On 19.04.2023 17:42, Oleksii Kurochko wrote:
>>> + /* panic(), aren't ready now.
>>> */
>>> + die();
>>> + }
>>> + }
>>> +
Hi,
On 24/04/2023 10:33, Jan Beulich wrote:
On 21.04.2023 16:41, Oleksii wrote:
On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
On 19.04.2023 17:42, Oleksii Kurochko wrote:
+ *
===
=
+ * Start addr | End add
On 20/04/2023 12:02, mark.s...@citrix.com wrote:
From: Mark Syms
Ensure the PV ring is drained on disconnect. Also ensure all pending
AIO is complete, otherwise AIO tries to complete into a mapping of the
ring which has been torn down.
Signed-off-by: Mark Syms
---
CC: Stefano Stabellini
CC:
On 24.04.2023 12:22, Julien Grall wrote:
> Hi,
>
> On 24/04/2023 10:33, Jan Beulich wrote:
>> On 21.04.2023 16:41, Oleksii wrote:
>>> On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
On 19.04.2023 17:42, Oleksii Kurochko wrote:
> + *
>
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 03/17] xen/arm: implement node distance helpers for
> Arm
>
> On 23.04.2023 07:36, Henry Wang wrote:
> >> -Original Message-
> >> From: Jan Beulich
> However, looking at the code below, don't you mean
Hi Jan,
On 24/04/2023 11:45, Jan Beulich wrote:
On 24.04.2023 12:22, Julien Grall wrote:
Hi,
On 24/04/2023 10:33, Jan Beulich wrote:
On 21.04.2023 16:41, Oleksii wrote:
On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
On 19.04.2023 17:42, Oleksii Kurochko wrote:
+ *
==
On 24.04.2023 13:02, Henry Wang wrote:
>> -Original Message-
>> From: Jan Beulich
>>
>> On 23.04.2023 07:36, Henry Wang wrote:
-Original Message-
From: Jan Beulich
>> However, looking at the code below, don't you mean to have the array
>> pre-set to all NUMA_NO_D
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 03/17] xen/arm: implement node distance helpers for
> Arm
> >>> Correct, I agree. I added a numa_init_distance() function (in patch #12)
> >>> to
> >>> set all values to NUMA_NO_DISTANCE. The numa_init_distance() w
On 24.04.2023 08:02, Luca Fancellu wrote:
> @@ -30,9 +37,11 @@ int sve_context_init(struct vcpu *v);
> void sve_context_free(struct vcpu *v);
> void sve_save_state(struct vcpu *v);
> void sve_restore_state(struct vcpu *v);
> +bool sve_domctl_vl_param(int val, unsigned int *out);
>
> #else /*
Hello,
Thanks guys.
I found out where the problem was.
Now dom0 booted more. But I have a new one.
This is a kernel panic during Dom0 loading.
Maybe someone is able to suggest something ?
Regards,
O.
[3.771362] sfp_register_bus: upstream ops attach
[3.776119] sfp_register_bus: Bus regist
On 21.04.2023 15:59, Juergen Gross wrote:
> Today it is not possible to analyse crash dumps of a system in
> hypervisor mode when it had been booted via EFI, as the crash utility
> doesn't understand the file format of xen.efi.
>
> This can easily be solved by creating an ELF file from xen.efi via
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>
>
> Some Arm based hardware platforms which does not support LPAE
> (eg Cortex-R52), uses 32 bit physical addresses.
> Also, users may choose to use 32 bits to represent physical addresses
> for optimization.
>
> To support the above use
Copying in Tim who did the final phase of the changes.
On Mon, 24 Apr 2023 at 11:32, Paul Durrant wrote:
>
> On 20/04/2023 12:02, mark.s...@citrix.com wrote:
> > From: Mark Syms
> >
> > Ensure the PV ring is drained on disconnect. Also ensure all pending
> > AIO is complete, otherwise AIO tries
On 06.04.2023 05:57, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -272,6 +272,15 @@ out:
> return r;
> }
>
> +/*
> + * This function returns X86EMUL_UNHANDLEABLE even if write is properly
> + * handled, to propagate it to the device
On Mon, Apr 24, 2023 at 1:08 PM Mark Syms wrote:
>
> Copying in Tim who did the final phase of the changes.
>
> On Mon, 24 Apr 2023 at 11:32, Paul Durrant wrote:
> >
> > On 20/04/2023 12:02, mark.s...@citrix.com wrote:
> > > From: Mark Syms
> > >
> > > Ensure the PV ring is drained on disconnect
On 24.04.23 14:01, Jan Beulich wrote:
On 21.04.2023 15:59, Juergen Gross wrote:
Today it is not possible to analyse crash dumps of a system in
hypervisor mode when it had been booted via EFI, as the crash utility
doesn't understand the file format of xen.efi.
This can easily be solved by creati
On Mon, 2023-04-24 at 11:25 +0200, Jan Beulich wrote:
> On 21.04.2023 16:41, Oleksii wrote:
> > On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
> > > On 19.04.2023 17:42, Oleksii Kurochko wrote:
> > > > + *
> > > > ===
> > > >
>
On 24/04/2023 14:17, Tim Smith wrote:
On Mon, Apr 24, 2023 at 1:08 PM Mark Syms wrote:
Copying in Tim who did the final phase of the changes.
On Mon, 24 Apr 2023 at 11:32, Paul Durrant wrote:
On 20/04/2023 12:02, mark.s...@citrix.com wrote:
From: Mark Syms
Ensure the PV ring is drained
On Mon, 2023-04-24 at 11:33 +0200, Jan Beulich wrote:
> On 21.04.2023 16:41, Oleksii wrote:
> > On Thu, 2023-04-20 at 14:58 +0200, Jan Beulich wrote:
> > > On 19.04.2023 17:42, Oleksii Kurochko wrote:
> > > > + *
> > > > ===
> > > >
>
On 06.04.2023 05:57, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -181,15 +181,21 @@ static bool msixtbl_initialised(const struct domain *d)
> }
>
> static struct msixtbl_entry *msixtbl_find_entry(
> -struct vcpu *v, unsigned long ad
Hi Jan,
> On 24 Apr 2023, at 12:34, Jan Beulich wrote:
>
> On 24.04.2023 08:02, Luca Fancellu wrote:
>> @@ -30,9 +37,11 @@ int sve_context_init(struct vcpu *v);
>> void sve_context_free(struct vcpu *v);
>> void sve_save_state(struct vcpu *v);
>> void sve_restore_state(struct vcpu *v);
>> +bool s
On 24.04.2023 16:00, Luca Fancellu wrote:
>> On 24 Apr 2023, at 12:34, Jan Beulich wrote:
>> On 24.04.2023 08:02, Luca Fancellu wrote:
>>> @@ -30,9 +37,11 @@ int sve_context_init(struct vcpu *v);
>>> void sve_context_free(struct vcpu *v);
>>> void sve_save_state(struct vcpu *v);
>>> void sve_resto
On 24.04.2023 15:44, Juergen Gross wrote:
> On 24.04.23 14:01, Jan Beulich wrote:
>> Finally - do you really need to copy all the non-debug sections as well?
>> Might --only-keep-debug be helpful here (provided it works for a PE/COFF
>> -> ELF copy operation; it looks to do so in my simple experime
flight 180391 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180391/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 13 debian-fixup fail in 180381 pass in 180391
test-amd64-amd64-xl-qemut-debian
Hi Jan,
Jan Beulich writes:
> On 21.04.2023 16:13, Volodymyr Babchuk wrote:
>>
>> Hi Roger,
>>
>> Roger Pau Monné writes:
>>
>>> On Fri, Apr 21, 2023 at 11:00:23AM +, Volodymyr Babchuk wrote:
Hello Roger,
Roger Pau Monné writes:
> On Mon, Apr 17, 2023 at 12
On 06.04.2023 05:57, Marek Marczykowski-Górecki wrote:
> Some firmware/devices are found to not reset MSI-X properly, leaving
> MASKALL set. Jason reports on his machine MASKALL persists through a
> warm reboot, but is cleared on cold boot. Xen relies on initial state
> being MASKALL clear. Especia
On 24.04.23 16:09, Jan Beulich wrote:
On 24.04.2023 15:44, Juergen Gross wrote:
On 24.04.23 14:01, Jan Beulich wrote:
Finally - do you really need to copy all the non-debug sections as well?
Might --only-keep-debug be helpful here (provided it works for a PE/COFF
-> ELF copy operation; it looks
On 24.04.2023 16:15, Volodymyr Babchuk wrote:
>
> Hi Jan,
>
> Jan Beulich writes:
>
>> On 21.04.2023 16:13, Volodymyr Babchuk wrote:
>>>
>>> Hi Roger,
>>>
>>> Roger Pau Monné writes:
>>>
On Fri, Apr 21, 2023 at 11:00:23AM +, Volodymyr Babchuk wrote:
>
> Hello Roger,
>
Today it is not possible to analyse crash dumps of a system in
hypervisor mode when it had been booted via EFI, as the crash utility
doesn't understand the file format of xen.efi.
This can easily be solved by creating an ELF file from xen.efi via
objcopy. Using that file as name list for crash ena
On 24.04.2023 16:30, Juergen Gross wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -226,6 +226,9 @@ endif
> $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(orphan-handling-y)
> $(note_file_option) -o $@
> $(NM) -pa --format=sysv $(@D)/$(@F) \
> | $(obj
> On 24 Apr 2023, at 15:05, Jan Beulich wrote:
>
> On 24.04.2023 16:00, Luca Fancellu wrote:
>>> On 24 Apr 2023, at 12:34, Jan Beulich wrote:
>>> On 24.04.2023 08:02, Luca Fancellu wrote:
@@ -30,9 +37,11 @@ int sve_context_init(struct vcpu *v);
void sve_context_free(struct vcpu *v);
On 24.04.2023 16:57, Luca Fancellu wrote:
>> On 24 Apr 2023, at 15:05, Jan Beulich wrote:
>> On 24.04.2023 16:00, Luca Fancellu wrote:
On 24 Apr 2023, at 12:34, Jan Beulich wrote:
On 24.04.2023 08:02, Luca Fancellu wrote:
> @@ -30,9 +37,11 @@ int sve_context_init(struct vcpu *v);
>>
On 24.04.2023 10:20, Xenia Ragiadakou wrote:
> This patch series aims to make the msr intercept handling, performed in
> vpmu code, virtualization technology agnostic.
> It creates a common interface for setting/clearing the msr intercepts and
> then add hooks to the corresponding hvm_funcs table t
On Mon, 2023-04-24 at 12:18 +0200, Jan Beulich wrote:
> On 21.04.2023 18:01, Oleksii wrote:
> > On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich wrote:
> > > On 19.04.2023 17:42, Oleksii Kurochko wrote:
> > > > + /* panic(), aren't ready
> > > > now.
> > > > */
> > > > +
On 24.04.23 16:50, Jan Beulich wrote:
On 24.04.2023 16:30, Juergen Gross wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -226,6 +226,9 @@ endif
$(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(orphan-handling-y)
$(note_file_option) -o $@
$(NM) -pa --format=sysv $(@D
> On 24 Apr 2023, at 16:06, Jan Beulich wrote:
>
> On 24.04.2023 16:57, Luca Fancellu wrote:
>>> On 24 Apr 2023, at 15:05, Jan Beulich wrote:
>>> On 24.04.2023 16:00, Luca Fancellu wrote:
> On 24 Apr 2023, at 12:34, Jan Beulich wrote:
> On 24.04.2023 08:02, Luca Fancellu wrote:
>>
On 24.04.2023 17:18, Luca Fancellu wrote:
>> On 24 Apr 2023, at 16:06, Jan Beulich wrote:
>> On 24.04.2023 16:57, Luca Fancellu wrote:
On 24 Apr 2023, at 15:05, Jan Beulich wrote:
On 24.04.2023 16:00, Luca Fancellu wrote:
>> On 24 Apr 2023, at 12:34, Jan Beulich wrote:
>> On 24
On Mon, Apr 24, 2023 at 10:19 AM Jan Beulich wrote:
>
> On 06.04.2023 05:57, Marek Marczykowski-Górecki wrote:
> > Some firmware/devices are found to not reset MSI-X properly, leaving
> > MASKALL set. Jason reports on his machine MASKALL persists through a
> > warm reboot, but is cleared on cold b
On 24.04.2023 17:25, Jason Andryuk wrote:
> On Mon, Apr 24, 2023 at 10:19 AM Jan Beulich wrote:
>> Jason - any chance of getting a Tested-by: from you?
>
> I'm building v3 now. v2 worked for clearing MASKALL on initial boot.
>
> I posted in these two messages - a summary is below.
> https://lo
> On 24 Apr 2023, at 16:25, Jan Beulich wrote:
>
> On 24.04.2023 17:18, Luca Fancellu wrote:
>>> On 24 Apr 2023, at 16:06, Jan Beulich wrote:
>>> On 24.04.2023 16:57, Luca Fancellu wrote:
> On 24 Apr 2023, at 15:05, Jan Beulich wrote:
> On 24.04.2023 16:00, Luca Fancellu wrote:
>>
On Mon, Apr 24, 2023 at 11:25:01AM -0400, Jason Andryuk wrote:
> On Mon, Apr 24, 2023 at 10:19 AM Jan Beulich wrote:
> >
> > On 06.04.2023 05:57, Marek Marczykowski-Górecki wrote:
> > > Some firmware/devices are found to not reset MSI-X properly, leaving
> > > MASKALL set. Jason reports on his mac
On 24.04.2023 17:16, Oleksii wrote:
> On Mon, 2023-04-24 at 12:18 +0200, Jan Beulich wrote:
>> On 21.04.2023 18:01, Oleksii wrote:
>>> On Thu, 2023-04-20 at 16:36 +0200, Jan Beulich wrote:
On 19.04.2023 17:42, Oleksii Kurochko wrote:
> + csr_write(CSR_SATP,
> + ((unsign
On 24.04.2023 17:34, Luca Fancellu wrote:
>> On 24 Apr 2023, at 16:25, Jan Beulich wrote:
>> On 24.04.2023 17:18, Luca Fancellu wrote:
On 24 Apr 2023, at 16:06, Jan Beulich wrote:
On 24.04.2023 16:57, Luca Fancellu wrote:
>> On 24 Apr 2023, at 15:05, Jan Beulich wrote:
>> On 24
> On 24 Apr 2023, at 16:41, Jan Beulich wrote:
>
> On 24.04.2023 17:34, Luca Fancellu wrote:
>>> On 24 Apr 2023, at 16:25, Jan Beulich wrote:
>>> On 24.04.2023 17:18, Luca Fancellu wrote:
> On 24 Apr 2023, at 16:06, Jan Beulich wrote:
> On 24.04.2023 16:57, Luca Fancellu wrote:
>>
On 24.04.2023 17:43, Luca Fancellu wrote:
>> On 24 Apr 2023, at 16:41, Jan Beulich wrote:
>> On 24.04.2023 17:34, Luca Fancellu wrote:
On 24 Apr 2023, at 16:25, Jan Beulich wrote:
On 24.04.2023 17:18, Luca Fancellu wrote:
> Oh ok, I don’t know, here what I get if for example I build
On Mon, Apr 24, 2023 at 11:30 AM Jan Beulich wrote:
>
> On 24.04.2023 17:25, Jason Andryuk wrote:
> > On Mon, Apr 24, 2023 at 10:19 AM Jan Beulich wrote:
> >> Jason - any chance of getting a Tested-by: from you?
> >
> > I'm building v3 now. v2 worked for clearing MASKALL on initial boot.
> >
>
On Sat, Apr 15 2023 at 23:06, Thomas Gleixner wrote:
> On Sat, Apr 15 2023 at 09:22, Brian Gerst wrote:
>> On Fri, Apr 14, 2023 at 7:45 PM Thomas Gleixner wrote:
>>> @@ -248,10 +311,20 @@ SYM_INNER_LABEL(secondary_startup_64_no_
>>> *
>>> * RDX contains the per-cpu offset
>>>
Dear Thomas,
Am 20.04.23 um 21:10 schrieb Thomas Gleixner:
On Thu, Apr 20 2023 at 18:47, Paul Menzel wrote:
Am 20.04.23 um 17:57 schrieb Thomas Gleixner:
I quickly applied it on top of your branch, but I am getting:
As I said it was untested. I was traveling and did not have access to a
mach
On Wed, Apr 19, 2023 at 8:55 AM Juergen Gross wrote:
>
> On 19.04.23 12:06, Olaf Hering wrote:
> > gcc13 fails to track the allocated memory in backup_ptes:
> >
> > xg_offline_page.c: In function 'backup_ptes':
> > xg_offline_page.c:191:13: error: pointer 'orig' may be used after 'realloc'
> > [-
flight 180394 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180394/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail in 180389 pass in 180394
test-amd64-i386-pair 28 guest-m
Hi Oleg,
Here is the issue from your logs:
SError Interrupt on CPU0, code 0xbe00 -- SError
SErrors are special signals to notify software of serious hardware
errors. Something is going very wrong. Defective hardware is a
possibility. Another possibility if software accessing address range
This is necessary to start HVM guests in subsequent tests.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/tests-artifacts/alpine/3.12.dockerfile | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/tests-artifacts/alpine/3.12.dockerfile
b/automation/tests-artifacts/alpine/3.
This series adds passthrough tests using the ADL x86 hw gitlab runner. Some of
the patches are improves existing hw tests too.
Example passing run:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/846920786
Marek Marczykowski-Górecki (6):
automation: specify explicit dom0 mem size
The login prompt is printed after all the startup (test) scripts, wait
for that instead of "passed" marker. And only then check if test passed.
Before this patch there was a race: "passed" marker could be already
printed, but the final check would fail because login prompt wasn't
there yet.
Signed
Avoid memory fragmentation that leads to:
(XEN) common/memory.c:277:d0v10 Could not allocate order=9 extent: id=1
memflags=0xc0 (0 of 4)
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automatio
It seems to build just fine with Alpine 3.12, and SeaBIOS is necessary
for a HVM test (that use the Alpine build).
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/build | 2 --
1 file changed, 2 deletions(-)
diff --git a/automation/scripts/build b/automation/scripts/build
index
Add simple PCI passthrough test to both PV and HVM domU. It passes
through a network adapter (the only one in the system), gets an IP via
DHCP (first basic test) and then ping the gateway (second basic test).
Finally, if device is supposed to use MSI or MSI-X (as set in the
PCIDEV_INTR test variabl
Make it a bit easier to see what has failed.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/scripts/qubes-x86-64.sh
b/automation/scripts/qubes-x86-64.sh
index 6442f7dda515..9b89d90f653c 100755
--- a
When creating a domU, but the creation fails, we may end up in a state
where a vcpu has not yet been added to the null scheduler, but
unit_deassign() is invoked. In this case, when running a debug build of
Xen, we will hit an ASSERT and crash Xen:
(XEN)
(XE
pci_serial_early_init() enables PCI_COMMAND_IO for IO-based UART
devices, do similar with PCI_COMMAND_MEMORY for MMIO-based UART devices.
Signed-off-by: Marek Marczykowski-Górecki
---
This fixes the issue I was talking about on #xendevel. Thanks Roger for
the hint.
---
xen/drivers/char/ns16550.c
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> Avoid memory fragmentation that leads to:
> (XEN) common/memory.c:277:d0v10 Could not allocate order=9 extent: id=1
> memflags=0xc0 (0 of 4)
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> This is necessary to start HVM guests in subsequent tests.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Stefano Stabellini
> ---
> automation/tests-artifacts/alpine/3.12.dockerfile | 1 +
> 1 file changed, 1 insertion(+)
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> The login prompt is printed after all the startup (test) scripts, wait
> for that instead of "passed" marker. And only then check if test passed.
> Before this patch there was a race: "passed" marker could be already
> printed, but the final
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> Make it a bit easier to see what has failed.
>
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> automation/scripts/qubes-x86-64.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/automation/scripts/qubes-x86-64.sh
> b/automat
On Mon, Apr 24, 2023 at 05:39:19PM -0700, Stefano Stabellini wrote:
> On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> > Make it a bit easier to see what has failed.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
> > ---
> > automation/scripts/qubes-x86-64.sh | 1 +
> > 1 file changed
flight 180395 linux-linus real [real]
flight 180399 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180395/
http://logs.test-lab.xenproject.org/osstest/logs/180399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> It seems to build just fine with Alpine 3.12, and SeaBIOS is necessary
> for a HVM test (that use the Alpine build).
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Stefano Stabellini
> ---
> automation/scripts/build | 2 --
On Mon, 24 Apr 2023, Marek Marczykowski-Górecki wrote:
> Add simple PCI passthrough test to both PV and HVM domU. It passes
> through a network adapter (the only one in the system), gets an IP via
> DHCP (first basic test) and then ping the gateway (second basic test).
> Finally, if device is suppo
flight 180396 xen-4.17-testing real [real]
flight 180402 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180396/
http://logs.test-lab.xenproject.org/osstest/logs/180402/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
> On 24 Apr 2023, at 17:10, Jan Beulich wrote:
>
> On 24.04.2023 17:43, Luca Fancellu wrote:
>>> On 24 Apr 2023, at 16:41, Jan Beulich wrote:
>>> On 24.04.2023 17:34, Luca Fancellu wrote:
> On 24 Apr 2023, at 16:25, Jan Beulich wrote:
> On 24.04.2023 17:18, Luca Fancellu wrote:
>>
On 24.04.23 23:00, Stewart Hildebrand wrote:
When creating a domU, but the creation fails, we may end up in a state
where a vcpu has not yet been added to the null scheduler, but
unit_deassign() is invoked.
This is not really true. The vcpu has been added, but it was offline at
that time. This
92 matches
Mail list logo
