On 06.09.2024 00:51, Stefano Stabellini wrote:
> On Thu, 5 Sep 2024, Jan Beulich wrote:
>> On 05.09.2024 08:45, Chen, Jiqian wrote:
>>> HI,
>>>
>>> On 2024/9/4 14:04, Jan Beulich wrote:
On 04.09.2024 03:43, Stefano Stabellini wrote:
> On Tue, 3 Sep 2024, Jan Beulich wrote:
>> On 03.09.
On 06.09.2024 06:41, osstest service owner wrote:
> flight 187507 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/187507/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-xsm6
On 05.09.2024 18:37, Nicola Vetrini wrote:
> MISRA C Rule 18.2 states: "Subtraction between pointers shall
> only be applied to pointers that address elements of the same array".
>
> Subtractions between pointer where at least one symbol is a
> symbol defined by the linker are safe and thus deviat
On 05.09.2024 23:54, Andrew Cooper wrote:
> On 21/06/2024 9:19 pm, Andrew Cooper wrote:
>> All of CONFIG_SCHED_*, and CONFIG_HYPFS build fine.
>>
>> Add a stub for share_xen_page_with_guest(), which is all that is necessary to
>> make CONFIG_TRACEBUFFER build.
>>
>> No functional change.
>>
>> Sign
On 05.09.2024 18:10, Andrew Cooper wrote:
> On 05/09/2024 4:42 pm, Jan Beulich wrote:
>> On 05.09.2024 15:06, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -102,9 +102,6 @@ static void __init efi_arch_relocate_image(unsigned
>>> long delta)
flight 187507 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 187498
build-i386
flight 187512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187512/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bfb33c0e09b0cf05460168c00ec43817b835f897
baseline version:
ovmf 013d51771a67ff87e6cb1
flight 187505 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 187495
Tests which did n
On 06/09/2024 12:08 am, Stefano Stabellini wrote:
> On Wed, 4 Sep 2024, Andrew Cooper wrote:
>> ... and drop generic_hweight32().
>>
>> As noted previously, the only two users of hweight32() are in __init paths.
>>
>> The int-optimised form of generic_hweight() is only two instructions shorter
>> t
flight 187504 linux-linus real [real]
flight 187509 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187504/
http://logs.test-lab.xenproject.org/osstest/logs/187509/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On Wed, 4 Sep 2024, Andrew Cooper wrote:
> ... and drop generic_hweight{32,64}().
>
> This is identical on all architectures except ARM32. Add one extra SELF_TEST
> to check that hweight64() works when the input is split in half.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Rev
On Wed, 4 Sep 2024, Andrew Cooper wrote:
> ... and drop generic_hweight32().
>
> As noted previously, the only two users of hweight32() are in __init paths.
>
> The int-optimised form of generic_hweight() is only two instructions shorter
> than the long-optimised form, and even then only on archi
On Wed, 4 Sep 2024, Andrew Cooper wrote:
> They are no more. No functional change.
>
> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
On Thu, 5 Sep 2024, Nicola Vetrini wrote:
> MISRA C Rule 18.2 states: "Subtraction between pointers shall
> only be applied to pointers that address elements of the same array".
>
> Subtractions between pointer where at least one symbol is a
> symbol defined by the linker are safe and thus deviate
On Thu, 5 Sep 2024, Jan Beulich wrote:
> On 05.09.2024 08:45, Chen, Jiqian wrote:
> > HI,
> >
> > On 2024/9/4 14:04, Jan Beulich wrote:
> >> On 04.09.2024 03:43, Stefano Stabellini wrote:
> >>> On Tue, 3 Sep 2024, Jan Beulich wrote:
> On 03.09.2024 12:53, Chen, Jiqian wrote:
> > On 2024/9
Lots of files were picking these up transitively, including lib.h
However, lib.h needs __read_mostly for printk_once() and this has the side
effect of kicking the transitive can down the road.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Juli
None of these are used, not even transitively.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/x86/bzimage.c | 1 -
xen/arch/x86/dmi_scan.c
probe.c includes a large number of headers which are unused, and not from
churn so far as I can see in history. Strip back to a reasonable set.
One complication is that genapic.h has to include xen/cpumask.h because
there's no way to forward declare a cpumask_t.
Also strip trailing whitespace wh
These include {xen/asm}/cache.h but only want xen/sections.h.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/x86/acpi/cpu_idle.c| 3 ++-
xen/arch/x86/
This continues prior work done for PPC and RISCV. Patches 1-4 are some header
rearranging for x86, with the convenient side effect of letting ARM fall out
in the wash in patch 5.
I've done a reasonable amount of Gitlab CI work, but I cant claim to have
tried every possible combination. RANDCONFI
These are no longer needed.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
---
xen/arch/arm/include/asm/cache.h | 3 ---
xen/include/xen/cache.h | 5 -
2
On 21/06/2024 9:19 pm, Andrew Cooper wrote:
> All of CONFIG_SCHED_*, and CONFIG_HYPFS build fine.
>
> Add a stub for share_xen_page_with_guest(), which is all that is necessary to
> make CONFIG_TRACEBUFFER build.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Shawn Anastasi
Hi everyone,
The community call recording has been uploaded.
YouTube link:
https://youtu.be/bVnZtQWzLtI
Cryptpad file:
https://cryptpad.fr/pad/#/2/pad/view/iPdSDDD4+An7kt0UT1V32t9f-rfyEQ4wJWqYj5cZCmg/
Many thanks,
Kelly Choi
Community Manager
Xen Project
Hi Team
I am trying to bring-up Zephyr as a domU guest with Linux as dom0. My
devkit has an ARM-A55 core and currently, Xen support in Zephyr (
https://github.com/zephyrproject-rtos/zephyr) is limited with only timer
and GIC virtualized with support to a HVC console.
I am trying to add more devic
flight 187508 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187508/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 013d51771a67ff87e6cb17a57e156ef4b6f4ec54
baseline version:
ovmf 3151798123e1419e74ebe
MISRA C Rule 18.2 states: "Subtraction between pointers shall
only be applied to pointers that address elements of the same array".
Subtractions between pointer where at least one symbol is a
symbol defined by the linker are safe and thus deviated, because
the compiler cannot exploit the undefined
On 05/09/2024 5:34 pm, Frediano Ziglio wrote:
> On Thu, Sep 5, 2024 at 5:10 PM Andrew Cooper
> wrote:
>
> On 05/09/2024 4:42 pm, Jan Beulich wrote:
> > On 05.09.2024 15:06, Andrew Cooper wrote:
> >> --- a/xen/arch/x86/efi/efi-boot.h
> >> +++ b/xen/arch/x86/efi/efi-boot.h
> >> @
On Thu, Sep 5, 2024 at 5:10 PM Andrew Cooper
wrote:
> On 05/09/2024 4:42 pm, Jan Beulich wrote:
> > On 05.09.2024 15:06, Andrew Cooper wrote:
> >> --- a/xen/arch/x86/efi/efi-boot.h
> >> +++ b/xen/arch/x86/efi/efi-boot.h
> >> @@ -102,9 +102,6 @@ static void __init efi_arch_relocate_image(unsigned
On Wed, 4 Sept 2024 at 17:15, Edgar E. Iglesias
wrote:
>
> From: "Edgar E. Iglesias"
>
> The following changes since commit e638d685ec2a0700fb9529cbd1b2823ac4120c53:
>
> Open 9.2 development tree (2024-09-03 09:18:43 -0700)
>
> are available in the Git repository at:
>
> https://gitlab.com/ed
On 04/09/2024 10:59 am, scan-ad...@coverity.com wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 1 new defect(s) introduced to XenProject found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of
On 05/09/2024 4:42 pm, Jan Beulich wrote:
> On 05.09.2024 15:06, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -102,9 +102,6 @@ static void __init efi_arch_relocate_image(unsigned long
>> delta)
>> }
>> }
>>
>> -extern const s32 __tram
Currently mwait_idle driver in Xen only implements support for Intel CPUs.
Thus in order to reduce dead code in non-Intel build configurations it can
be made explicitly dependant on CONFIG_INTEL option.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/cpu/Makefile | 2 +-
xen/arch/x86/incl
flight 187501 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187501/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187489
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 04.09.2024 17:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1291,14 +1291,23 @@ static bool __get_cmos_time(struct rtc_time *rtc)
> return t1 <= SECONDS(1) && t2 < MILLISECS(3);
> }
>
> -static bool cmos_probe(struct rtc_time *rtc_p, bool cmos_r
On 04.09.2024 17:31, Roger Pau Monne wrote:
> The current logic to probe for the CMOS RTC is open-coded in get_cmos_time(),
> move it to a separate function that both serves the purpose of testing for the
> CMOS RTC existence and returning its value.
>
> The goal is to be able to split the probing
This section explains which format should be followed by header
inclusion guards via a drop-down list of rules.
No functional change.
Signed-off-by: Alessandro Zucchelli
---
Changes in v6:
- edit inclusion guards naming conventions, including more details
Changes in v5:
- edit inclusion guards
On 05/09/2024 4:47 pm, Jan Beulich wrote:
> On 05.09.2024 17:45, Andrew Cooper wrote:
>> On 05/09/2024 4:35 pm, Jan Beulich wrote:
>>> On 05.09.2024 15:06, Andrew Cooper wrote:
asm/config.h is included in every translation unit (via xen/config.h),
while
only a handful of functions a
On 05.09.2024 17:45, Andrew Cooper wrote:
> On 05/09/2024 4:35 pm, Jan Beulich wrote:
>> On 05.09.2024 15:06, Andrew Cooper wrote:
>>> asm/config.h is included in every translation unit (via xen/config.h), while
>>> only a handful of functions actually interact with the trampoline.
>>>
>>> Move the
On 04.09.2024 17:31, Roger Pau Monne wrote:
> Move the logic that ensures the CMOS RTC data is read just after it's been
> updated into the __get_cmos_time() function that does the register reads.
> This
> requires returning a boolean from __get_cmos_time() to signal whether the read
> has been s
On Wed, 2024-09-04 at 11:31 +0100, Andrew Cooper wrote:
> On 04/09/2024 11:27 am, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-09-03 at 15:21 +0100, Andrew Cooper wrote:
> > > On 02/09/2024 6:01 pm, Oleksii Kurochko wrote:
> > > > diff --git a/xen/arch/riscv/include/asm/atomic.h
> > > > b/xen
On 04.09.2024 17:31, Roger Pau Monne wrote:
> Move the current code in get_wallclock_time() to fetch the Xen wallclock
> information from the shared page when running as a guest into a separate
> helper.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 05/09/2024 4:35 pm, Jan Beulich wrote:
> On 05.09.2024 15:06, Andrew Cooper wrote:
>> asm/config.h is included in every translation unit (via xen/config.h), while
>> only a handful of functions actually interact with the trampoline.
>>
>> Move the infrastructure into its own header, and take the
On 05.09.2024 15:06, Andrew Cooper wrote:
> kbd_shift_flags seems especially dubious. It's a snapshot of the keyboard
> state when Xen happened to pass through the trampoline, and surely cannot be
> useful for dom0 in the slightest...
No more or less than if the kernel takes such a snapshot while
On 05/09/2024 4:05 pm, Alejandro Vallejo wrote:
> On Thu Sep 5, 2024 at 2:06 PM BST, Andrew Cooper wrote:
>> This removes a level of indirection, as well as removing a somewhat
>> misleading
>> name; the variable is really "S3 video quirks".
> nit: Would it be beneficial to rename video_flags to s
On 05.09.2024 15:06, Andrew Cooper wrote:
> asm/config.h is included in every translation unit (via xen/config.h), while
> only a handful of functions actually interact with the trampoline.
>
> Move the infrastructure into its own header, and take the opportunity to
> document everything.
>
> Als
flight 187498 xen-unstable real [real]
flight 187506 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187498/
http://logs.test-lab.xenproject.org/osstest/logs/187506/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Thu Sep 5, 2024 at 2:06 PM BST, Andrew Cooper wrote:
> This removes a level of indirection, as well as removing a somewhat misleading
> name; the variable is really "S3 video quirks".
nit: Would it be beneficial to rename video_flags to s3_video_flags?
>
> More importantly however it makes it
On 05.09.2024 15:06, Andrew Cooper wrote:
> This removes a level of indirection, as well as removing a somewhat misleading
> name; the variable is really "S3 video quirks".
>
> More importantly however it makes it very clear that, right now, parsing the
> cmdline and quirks depends on having alrea
On Thu, Sep 5, 2024 at 2:07 PM Andrew Cooper
wrote:
> This started while inspecting a preprossed file for bitops, but it turns
> out
> is relevant for Frediano's 32bit boot code changes too.
>
> Its header file juggling, and documentation with observations relevant to
> both
> the ASI and Host UE
On 04.09.2024 16:24, Andrew Cooper wrote:
> On 04/09/2024 1:28 pm, Jan Beulich wrote:
>> ---
>> Instead of ->read_segment() we could of course also use ->read_msr() to
>> fetch the original GS base. I don't think I can see a clear advantage of
>> either approach; the way it's done it matches how we
On 05/09/2024 2:17 pm, Jan Beulich wrote:
> Drop explicit {evex} pseudo-prefixes. New gas (validly) complains when
> they're used on other than instructions.
"other than" like this is awkward grammar. "things other than
instructions" would be better.
> Our use was potentially ahead
> of macro i
Drop explicit {evex} pseudo-prefixes. New gas (validly) complains when
they're used on other than instructions. Our use was potentially ahead
of macro invocations - see simd.h's "override" macro.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/simd.c
+++ b/tools/tests/x86_emulator/simd
This started while inspecting a preprossed file for bitops, but it turns out
is relevant for Frediano's 32bit boot code changes too.
Its header file juggling, and documentation with observations relevant to both
the ASI and Host UEFI Secureboot work, hence the extended CC list.
Andrew Cooper (3):
asm/config.h is included in every translation unit (via xen/config.h), while
only a handful of functions actually interact with the trampoline.
Move the infrastructure into its own header, and take the opportunity to
document everything.
Also change trampoline_realmode_entry() and wakeup_start()
... and document them too.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Frediano Ziglio
CC: Alejandro Vallejo
video.h, edd.h and e820.h also contain trampoline symbols, but they're pretty
well contained headers already.
kbd_shift_flags seem
This removes a level of indirection, as well as removing a somewhat misleading
name; the variable is really "S3 video quirks".
More importantly however it makes it very clear that, right now, parsing the
cmdline and quirks depends on having already placed the trampoline; a
dependency which is goin
On 05.09.2024 14:21, Andrew Cooper wrote:
> On 05/09/2024 12:36 pm, Jan Beulich wrote:
>> These being controlled by XCR0, enabling support is relatively
>> straightforward. Note however that there won't be any use of them until
>> their dependent ISA extension CPUID flags are exposed, not the least
On 05/09/2024 12:36 pm, Jan Beulich wrote:
> These being controlled by XCR0, enabling support is relatively
> straightforward. Note however that there won't be any use of them until
> their dependent ISA extension CPUID flags are exposed, not the least due
> to recalculate_xstate() handling the dep
On 04.09.2024 18:54, Andrew Cooper wrote:
> On 04/09/2024 1:29 pm, Jan Beulich wrote:
>> To represent the USER-MSR bitmap access, a new segment type needs
>> introducing, behaving like x86_seg_none in terms of address treatment,
>> but behaving like a system segment for page walk purposes (implicit
On 05.09.2024 12:41, Andrew Cooper wrote:
> On 05/09/2024 11:33 am, Jan Beulich wrote:
>> Hello,
>>
>> I happened to spot a ~14y old revert of the crucial hunk of the ~16y old
>> 551ceee97513 ("x86, hvm: stdvga cache always on") in our patch set,
>> supposedly to deal with text mode corruption when
These being controlled by XCR0, enabling support is relatively
straightforward. Note however that there won't be any use of them until
their dependent ISA extension CPUID flags are exposed, not the least due
to recalculate_xstate() handling the dependencies in kind of a reverse
manner.
Signed-off-
On 05/09/2024 11:41, Andrew Cooper wrote:
STDVGA caching is primarily (exclusively?) an optimisation for Windows XP.
I think it was originally for Win2K (white splash screen).
Paul
On 05/09/2024 11:33 am, Jan Beulich wrote:
> Hello,
>
> I happened to spot a ~14y old revert of the crucial hunk of the ~16y old
> 551ceee97513 ("x86, hvm: stdvga cache always on") in our patch set,
> supposedly to deal with text mode corruption when Linux is booted without
> any "vga=" option, and
Hello,
I happened to spot a ~14y old revert of the crucial hunk of the ~16y old
551ceee97513 ("x86, hvm: stdvga cache always on") in our patch set,
supposedly to deal with text mode corruption when Linux is booted without
any "vga=" option, and when - after the GUI is up - the console is
switched
flight 187503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187503/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3151798123e1419e74ebef1df73e9d651f1fcd3e
baseline version:
ovmf 03bc4252fb68f0dcba72a
flight 187497 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail REGR. vs. 187480
On 05.09.2024 00:55, Andrew Cooper wrote:
> Recent additions have undone prior tidying at the top of the file.
>
> Signed-off-by: Andrew Cooper
Looks like despite not getting any ack (nor comments) for this in earlier
rounds, you still want to keep it and you don't want to re-base subsequent
cha
On 05.09.2024 00:55, Andrew Cooper wrote:
> It has existed in x86 CPUs since 2008, so we're only 16 years late adding
> support. With all the other scafolding in place, implement arch_hweightl()
> for x86.
>
> The only complication is that the call to arch_generic_hweightl() is behind
> the compi
On 05.09.2024 08:45, Chen, Jiqian wrote:
> HI,
>
> On 2024/9/4 14:04, Jan Beulich wrote:
>> On 04.09.2024 03:43, Stefano Stabellini wrote:
>>> On Tue, 3 Sep 2024, Jan Beulich wrote:
On 03.09.2024 12:53, Chen, Jiqian wrote:
> On 2024/9/3 17:25, Jan Beulich wrote:
>> On 03.09.2024 09:58
flight 187502 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187502/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 03bc4252fb68f0dcba72a19e1b2a861a5d6c927e
baseline version:
ovmf 7b9f2018d1f2a850eca2c
70 matches
Mail list logo
