On 05.01.2023 23:28, Andrew Cooper wrote:
> On 05/01/2023 8:15 am, Jan Beulich wrote:
>> On 04.01.2023 19:34, Andrew Cooper wrote:
>>> On 04/01/2023 5:04 pm, Jan Beulich wrote:
On 03.01.2023 21:09, Andrew Cooper wrote:
> +if ( sz > INT32_MAX )
> +return -E2BIG; /* Compat gu
On 05.01.2023 23:17, Andrew Cooper wrote:
> On 05/01/2023 7:57 am, Jan Beulich wrote:
>> On 04.01.2023 20:55, Andrew Cooper wrote:
>>> On 04/01/2023 4:40 pm, Jan Beulich wrote:
On 03.01.2023 21:09, Andrew Cooper wrote:
> A split in virtual address space is only applicable for x86 PV guests
flight 175598 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175598/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c2357809e2c352c8ba7c35ab50f49deefd3d39e
baseline version:
ovmf c32e7331513bfdb625986
On 05.01.2023 18:50, Julien Grall wrote:
> On 05/01/2023 16:46, Jan Beulich wrote:
>> On 16.12.2022 12:48, Julien Grall wrote:
>>> --- a/xen/arch/x86/include/asm/fixmap.h
>>> +++ b/xen/arch/x86/include/asm/fixmap.h
>>> @@ -21,6 +21,8 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> +
>>
On 05.01.2023 21:28, Andrew Cooper wrote:
> On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
>> diff --git a/docs/misc/xen-command-line.pandoc
>> b/docs/misc/xen-command-line.pandoc
>> index
>> 424b12cfb27d6ade2ec63eacb8afe5df82465451..0230a7bc17cbd4362a42ea64cea695f31f5e0f86
>> 100644
>> --- a
flight 175591 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-li
flight 175596 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175596/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c32e7331513bfdb625986e4570c304dced4ea109
baseline version:
ovmf 9ce09870e721efacc41fa
On Fri, Jan 06, 2023 at 03:30:01AM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 05, 2023 at 09:00:03PM -0500, Demi Marie Obenour wrote:
> > On Thu, Jan 05, 2023 at 08:28:26PM +, Andrew Cooper wrote:
> > > On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
> > > > diff --git a/docs/misc
On Thu, Jan 05, 2023 at 09:00:03PM -0500, Demi Marie Obenour wrote:
> On Thu, Jan 05, 2023 at 08:28:26PM +, Andrew Cooper wrote:
> > On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
> > > diff --git a/docs/misc/xen-command-line.pandoc
> > > b/docs/misc/xen-command-line.pandoc
> > > index
> >
On 05/01/2023 3:57 pm, Jan Beulich wrote:
> ... or so I hope. The main observation was that we still have both
> hash_vcpu_for_each() and hash_domain_for_each(), where the latter was
foreach
> introduced in 2014/15 to replace the former. Only some eight years
> later we can now complete this conv
On 05/01/2023 4:05 pm, Jan Beulich wrote:
> The "n" input is a GFN value and hence bounded by the physical address
> bits in use on a system.
The one case where this isn't obviously true is in sh_audit(). It comes
from a real MFN in the system, not a GFN, which will have the same
property WRT PAD
On Thu, Jan 05, 2023 at 08:28:26PM +, Andrew Cooper wrote:
> On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
> > diff --git a/docs/misc/xen-command-line.pandoc
> > b/docs/misc/xen-command-line.pandoc
> > index
> > 424b12cfb27d6ade2ec63eacb8afe5df82465451..0230a7bc17cbd4362a42ea64cea695f31f5
flight 175590 qemu-mainline real [real]
flight 175594 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175590/
http://logs.test-lab.xenproject.org/osstest/logs/175594/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 05/01/2023 4:05 pm, Jan Beulich wrote:
> Like for the various HVM-only types, save a little bit of code by suitably
> "masking" this type out when !PV32.
add/remove: 0/1 grow/shrink: 2/4 up/down: 544/-922 (-378)
Function old new delta
sh_map_and_validat
On 05/01/2023 4:04 pm, Jan Beulich wrote:
> v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
> v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
fixup[],smfn[] ?
On 05/01/2023 4:04 pm, Jan Beulich wrote:
> Perhaps these should have been dropped right in 2fb2dee1ac62 ("x86/mm:
> pagetable_dying() is HVM-only"). Convert both to assertions, noting that
> in particular the one in the 3-level variant of the function comes too
"came too late"?
It doesn't any mo
On 05/01/2023 3:59 pm, Jan Beulich wrote:
> Rather than doing a separate hash walk (and then even using the vCPU
> variant, which is to go away), do the up-pointer-clearing right in
> sh_unpin(), as an alternative to the (now further limited) enlisting on
> a "free floating" list fragment. This uti
On 05/01/2023 1:20 pm, Sergey Dyasli wrote:
> The original issue has been reported on AMD Bulldozer-based CPUs where
> ucode loading loses the LWP feature bit in order to gain the IBPB bit.
> LWP disabling is per-SMT core modification and needs to happen on each
> sibling SMT thread despite the sha
flight 175593 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175593/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 05/01/2023 8:15 am, Jan Beulich wrote:
> On 04.01.2023 19:34, Andrew Cooper wrote:
>> On 04/01/2023 5:04 pm, Jan Beulich wrote:
>>> On 03.01.2023 21:09, Andrew Cooper wrote:
API/ABI wise, XENVER_build_id could be merged into xenver_varstring_op(),
but
the internal infrastructure
On 05/01/2023 7:57 am, Jan Beulich wrote:
> On 04.01.2023 20:55, Andrew Cooper wrote:
>> On 04/01/2023 4:40 pm, Jan Beulich wrote:
>>> On 03.01.2023 21:09, Andrew Cooper wrote:
A split in virtual address space is only applicable for x86 PV guests.
Furthermore, the information returned for
On 1/4/23 3:47 PM, Chuck Zmudzinski wrote:
> On 1/3/23 10:14 AM, Alex Williamson wrote:
>
>>
>> It's necessary to configure the assigned IGD at slot 2 to make it
>> functional, yes, but I don't really understand this notion of
>> "reserving" slot 2. If something occupies address 00:02.0 in the
>
There are two paths in the trampoline, and Xen's PAT needs setting up in both,
not just the boot path.
Fixes: 4304ff420e51 ("x86/S3: Drop {save,restore}_rest_processor_state()
completely")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Marek Marczykowski-
On 22/12/2022 10:31 pm, Demi Marie Obenour wrote:
> diff --git a/docs/misc/xen-command-line.pandoc
> b/docs/misc/xen-command-line.pandoc
> index
> 424b12cfb27d6ade2ec63eacb8afe5df82465451..0230a7bc17cbd4362a42ea64cea695f31f5e0f86
> 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/mi
On 05/01/2023 2:01 pm, Jan Beulich wrote:
> On 22.12.2022 23:31, Demi Marie Obenour wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -6352,6 +6352,11 @@ unsigned long get_upper_mfn_bound(void)
>> return min(max_mfn, 1UL << (paddr_bits - PAGE_SHIFT)) - 1;
>> }
>>
>> +
>> +/
On 22/12/2022 8:00 am, Jan Beulich wrote:
> On 21.12.2022 18:43, Andrew Cooper wrote:
>> On 21/12/2022 1:25 pm, Jan Beulich wrote:
>>> The hook isn't mode dependent, hence it's misplaced in struct
>>> paging_mode. (Or alternatively I see no reason why the alloc_page() and
>>> free_page() hooks don'
flight 175589 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175589/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 175579 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-li
On 22/12/2022 7:51 am, Jan Beulich wrote:
> On 21.12.2022 18:16, Andrew Cooper wrote:
>> On 21/12/2022 1:25 pm, Jan Beulich wrote:
>>> + d, d->arch.paging.total_pages,
>>> + d->arch.paging.free_pages, d->arch.paging.p2m_pages);
>>> +
>>> +if ( hap )
>>>
Hi Jan,
On 05/01/2023 16:46, Jan Beulich wrote:
On 16.12.2022 12:48, Julien Grall wrote:
--- a/xen/arch/x86/include/asm/fixmap.h
+++ b/xen/arch/x86/include/asm/fixmap.h
@@ -21,6 +21,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -54,6 +56,8 @@ enum fixed_ad
On 16.12.2022 12:48, Julien Grall wrote:
> PMAP will be used in a follow-up patch to bootstap map domain
> page infrastructure -- we need some way to map pages to setup the
> mapcache without a direct map.
But this isn't going to be needed overly early then, seeing that ...
> --- a/xen/arch/x86/i
On 05/01/2023 4:24 pm, Oleksii wrote:
> On Thu, 2023-01-05 at 18:10 +0200, Oleksii wrote:
>> On Thu, 2023-01-05 at 15:48 +, Andrew Cooper wrote:
>>> On 05/01/2023 1:40 pm, Jan Beulich wrote:
On 05.01.2023 13:01, Oleksii Kurochko wrote:
> To run in debug mode should be done the followin
On Thu, 2023-01-05 at 18:10 +0200, Oleksii wrote:
> On Thu, 2023-01-05 at 15:48 +, Andrew Cooper wrote:
> > On 05/01/2023 1:40 pm, Jan Beulich wrote:
> > > On 05.01.2023 13:01, Oleksii Kurochko wrote:
> > > > To run in debug mode should be done the following instructions:
> > > > $ qemu-system
On Thu, 2023-01-05 at 15:48 +, Andrew Cooper wrote:
> On 05/01/2023 1:40 pm, Jan Beulich wrote:
> > On 05.01.2023 13:01, Oleksii Kurochko wrote:
> > > To run in debug mode should be done the following instructions:
> > > $ qemu-system-riscv64 -M virt -smp 1 -nographic -m 2g \
> > > -ke
All callers live in hvm.c. Moving the function there is undesirable, as
hash walking is local to common.c and probably better remains so. Hence
move an #endif, allowing to drop an #ifdef.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1
In sh_remove_shadow_via_pointer() the type range checks, besides being
bogus (should be ">= min && <= max"), are fully redundant with the has-
up-pointer assertion. In sh_hash_audit_bucket() properly use "min"
instead of assuming a certain order of type numbers.
Signed-off-by: Jan Beulich
---
Whi
In both cases the "entry_pa != 0" check is redundant; storing 0 when the
field already is 0 is quite fine. Move the cheaper remaining part first
in sh_get_ref(). In sh_put_ref() convert the has-up-pointer check into
an assertion (requiring the zero check to be retained there).
Signed-off-by: Jan B
The "n" input is a GFN value and hence bounded by the physical address
bits in use on a system. The hash quality won't improve by also
including the upper always-zero bits in the calculation. To keep things
as compile-time-constant as they were before, use PADDR_BITS (not
paddr_bits) for loop bound
Like for the various HVM-only types, save a little bit of code by suitably
"masking" this type out when !PV32.
Signed-off-by: Jan Beulich
---
I wasn't really sure whether it would be worthwhile to also update the
"#else" part of shadow_size(). Doing so would be a little tricky, as the
type to ret
v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
hash table are all only ever written with valid MFNs or INVALID_MFN.
Avoid the somewhat expensive mfn_valid() when checking MFNs coming from
these arrays.
Signed-
Perhaps these should have been dropped right in 2fb2dee1ac62 ("x86/mm:
pagetable_dying() is HVM-only"). Convert both to assertions, noting that
in particular the one in the 3-level variant of the function comes too
late anyway - first thing there we access the HVM part of a union.
Signed-off-by: J
The "domain" in there has become meaningless; drop it.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,15 +1640,15 @@ bool shadow_hash_delete(struct domain *d
return true;
}
-typedef int (*hash_domain_callback_t)(struct doma
The domain based variant is easily usable by shadow_audit_tables(); all
that's needed is conversion of the callback functions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,59 +1640,11 @@ bool shadow_hash_delete(struct domain *d
Nothing in there is vCPU-specific.
With the introduction of the local variable in sh_audit_l1_table(),
convert other uses of v->domain as well.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3919,13 +3919,13 @@ static void cf_check sh_pa
Rather than doing a separate hash walk (and then even using the vCPU
variant, which is to go away), do the up-pointer-clearing right in
sh_unpin(), as an alternative to the (now further limited) enlisting on
a "free floating" list fragment. This utilizes the fact that such list
fragments are traver
... or so I hope. The main observation was that we still have both
hash_vcpu_for_each() and hash_domain_for_each(), where the latter was
introduced in 2014/15 to replace the former. Only some eight years
later we can now complete this conversion. Everything else addresses
other things noticed along
On 05/01/2023 1:40 pm, Jan Beulich wrote:
> On 05.01.2023 13:01, Oleksii Kurochko wrote:
>> To run in debug mode should be done the following instructions:
>> $ qemu-system-riscv64 -M virt -smp 1 -nographic -m 2g \
>> -kernel xen/xen -s -S
>> # In separate terminal:
>> $ riscv64-buildroo
flight 175583 qemu-mainline real [real]
flight 175588 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175583/
http://logs.test-lab.xenproject.org/osstest/logs/175588/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 22.12.2022 23:31, Demi Marie Obenour wrote:
> Setting cacheability flags that are not ones specified by Xen is a bug
> in the guest. By default, return -EINVAL if a guests attempts to do
> this. The invalid-cacheability= Xen command-line flag allows the
> administrator to allow such attempts o
On 05/01/2023 11:10 am, Jan Beulich wrote:
> 1: macroize switches to/from .fixup section
> 2: split .fixup section with new enough gas
>
> Jan
Honestly, I was planning to make another effort to up the minimum
compiler versions to something which supports asm goto, and delete
.fixup entirely.
This
On 22.12.2022 23:31, Demi Marie Obenour wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6352,6 +6352,11 @@ unsigned long get_upper_mfn_bound(void)
> return min(max_mfn, 1UL << (paddr_bits - PAGE_SHIFT)) - 1;
> }
>
> +
> +/*
Nit: Please avoid introducing double blank lines.
Hi all,
NB that as discussed at the previous call, this month's community call is
NEXT THURSDAY, 12 January.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/9YJwttVUMtpCrgS4ZX3sbNyA/ and you can
edit to add items. Alternatively, you can reply to this mail directly.
Agenda items a
On 05.01.2023 13:01, Oleksii Kurochko wrote:
> To run in debug mode should be done the following instructions:
> $ qemu-system-riscv64 -M virt -smp 1 -nographic -m 2g \
> -kernel xen/xen -s -S
> # In separate terminal:
> $ riscv64-buildroot-linux-gnu-gdb
> $ target remote :1234
> $ add
The original issue has been reported on AMD Bulldozer-based CPUs where
ucode loading loses the LWP feature bit in order to gain the IBPB bit.
LWP disabling is per-SMT core modification and needs to happen on each
sibling SMT thread despite the shared microcode engine. Otherwise,
logical CPUs will e
flight 175577 libvirt real [real]
flight 175587 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175577/
http://logs.test-lab.xenproject.org/osstest/logs/175587/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-li
On 05/01/2023 11:19 am, Julien Grall wrote:
> On 05/01/2023 09:59, Ayan Kumar Halder wrote:
>> Hi Julien,
>
> Hi,
>
>> I have a clarification.
>>
>> On 05/01/2023 09:26, Julien Grall wrote:
>>> CAUTION: This message has originated from an External Source. Please
>>> use proper judgment and caution
On Wed, 2023-01-04 at 20:39 +, Andrew Cooper wrote:
> On 30/12/2022 1:01 pm, Oleksii Kurochko wrote:
> > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-
> > ci/build.yaml
> > index e6a9357de3..11eb1c6b82 100644
> > --- a/automation/gitlab-ci/build.yaml
> > +++ b/automation/git
On Wed, 2023-01-04 at 20:36 +, Andrew Cooper wrote:
> On 30/12/2022 1:01 pm, Oleksii Kurochko wrote:
> > The patch provides a minimal amount of changes to start
> > build and run minimal Xen binary at GitLab CI&CD that will
> > allow continuous checking of the build status of RISC-V Xen.
> >
>
On 05/01/2023 11:09 am, Jan Beulich wrote:
> First and foremost correct a comment implying the opposite. Then, to
> make things more clear PV-vs-HVM-wise, move the PV check earlier in the
> function, making it unnecessary for both callers to perform the check
> individually. Finally return NULL fro
Sorry for flooding but please skip review of patch series v3 as
I missed comments of Andrew so only v4 should be reviewed.
On Thu, 2023-01-05 at 10:40 +0200, Oleksii Kurochko wrote:
> The patch series introduces the following:
> - provide a minimal amount of changes to add initial RISC-V support
>
The patch series introduces the following:
- provide a minimal amount of changes to add initial RISC-V support
to make Xen binary buildable and runnable for RISC-V architecture
which can be used for future development and testing.
- add RISC-V 64 cross-compile build jobs to check if any new cha
Add build jobs to cross-compile Xen-only for RISC-V 64.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
Changes in V4:
- Add RISCV RANDCONFIG jobs
- Remove unnecessary comments
---
Changes in V2:
- Add HYPERVISOR_ONLY to RISCV jobs because after rebase on
top of the patch series
The patch provides a minimal amount of changes to start
build and run minimal Xen binary at GitLab CI&CD that will
allow continuous checking of the build status of RISC-V Xen.
Except introduction of new files the following changes were done:
* Redefinition of ALIGN define from '.align 2' to '.alig
On 05/01/2023 09:59, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
I have a clarification.
On 05/01/2023 09:26, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this
GNU as, as of version 2.26, allows deriving the name of a section to
switch to from the present section's name. For the replacement to occur
--sectname-subst needs to be passed to the assembler.
Signed-off-by: Jan Beulich
---
Similarly (and perhaps of more interest) we could split .ex_table,
allo
This centralizes section name and attribute setting, thus simplifying
future changes to either of these.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -57,10 +57,10 @@ static inline int rdmsr_amd_safe(unsigne
int err;
asm volatile("1: r
1: macroize switches to/from .fixup section
2: split .fixup section with new enough gas
Jan
First and foremost correct a comment implying the opposite. Then, to
make things more clear PV-vs-HVM-wise, move the PV check earlier in the
function, making it unnecessary for both callers to perform the check
individually. Finally return NULL from the function when using the idle
domain's page ta
On 05/01/2023 10:12 am, Jan Beulich wrote:
> Now that we have them available in a header which is okay to use from
> hvmloader sources, do away with respective literal numbers and silent
> assumptions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Now that we have them available in a header which is okay to use from
hvmloader sources, do away with respective literal numbers and silent
assumptions.
Signed-off-by: Jan Beulich
---
v2: Use simpler BCST() macro.
--- a/tools/firmware/hvmloader/cacheattr.c
+++ b/tools/firmware/hvmloader/cacheatt
Hi Julien,
I have a clarification.
On 05/01/2023 09:26, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
Hi Stefano,
On 04/01/2023 23:47, Stefano S
Hi Stefano,
On 04/01/2023 23:47, Stefano Stabellini wrote:
On Tue, 3 Jan 2023, Michal Orzel wrote:
Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.
Sig
From: Markus Armbruster
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the
header don't actually need them. Similar structs live in their own
headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in
pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h,
PCIExpressH
From: Markus Armbruster
hw/pci/pci_bridge.h and hw/cxl/cxl.h include each other.
Fortunately, breaking the loop is merely a matter of deleting
unnecessary includes from headers, and adding them back in places
where they are now missing.
Signed-off-by: Markus Armbruster
Message-Id: <20221222100
The function p2m_index is defined in the p2m.c file, but not called
elsewhere, so remove this unused function.
arch/x86/xen/p2m.c:137:24: warning: unused function 'p2m_index'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3557
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Cha
Add build jobs to cross-compile Xen-only for RISC-V 64.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
Changes in V2:
- Add HYPERVISOR_ONLY to RISCV jobs because after rebase on
top of the patch series "CI: Fixes/cleanup in preparation for RISCV"
it is required to set HYPERVI
The patch provides a minimal amount of changes to start
build and run minimal Xen binary at GitLab CI&CD that will
allow continuous checking of the build status of RISC-V Xen.
Except introduction of new files the following changes were done:
* Redefinition of ALIGN define from '.algin 2' to '.alig
The patch series introduces the following:
- provide a minimal amount of changes to add initial RISC-V support
to make Xen binary buildable and runnable for RISC-V architecture
which can be used for future development and testing.
- add RISC-V 64 cross-compile build jobs to check if any new cha
flight 175573 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175573/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail in 175569 pass
in 175573
test-amd64-i386-xl-qem
On 04.01.2023 19:34, Andrew Cooper wrote:
> On 04/01/2023 5:04 pm, Jan Beulich wrote:
>> On 03.01.2023 21:09, Andrew Cooper wrote:
>>> API/ABI wise, XENVER_build_id could be merged into xenver_varstring_op(),
>>> but
>>> the internal infrastructure is awkward.
>> I guess build-id also doesn't fit
80 matches
Mail list logo
