On 2024/9/13 14:52, Jan Beulich wrote:
> On 13.09.2024 04:38, Chen, Jiqian wrote:
>> On 2024/9/12 18:51, Jan Beulich wrote:
>>> On 12.09.2024 12:34, Daniel P. Smith wrote:
On 9/11/24 02:58, Jiqian Chen wrote:
> @@ -237,6 +238,34 @@ long arch_do_domctl(
> break;
> }
flight 187677 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187677/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187666
test-amd64-amd64-xl-qemut-win7-amd64
Hi Michal,
> On 13 Sep 2024, at 08:15, Michal Orzel wrote:
>
> The predefined configurations for early printk have been deprecated for
> a sufficient amount of time. Let's finally remove them.
>
> Note:
> In order not to loose these predefined configurations, I wrote a wiki
> page: https://wiki
On 13.09.2024 04:38, Chen, Jiqian wrote:
> On 2024/9/12 18:51, Jan Beulich wrote:
>> On 12.09.2024 12:34, Daniel P. Smith wrote:
>>> On 9/11/24 02:58, Jiqian Chen wrote:
@@ -237,6 +238,34 @@ long arch_do_domctl(
break;
}
+case XEN_DOMCTL_gsi_permissio
The predefined configurations for early printk have been deprecated for
a sufficient amount of time. Let's finally remove them.
Note:
In order not to loose these predefined configurations, I wrote a wiki
page: https://wiki.xenproject.org/wiki/Xen_on_ARM_Early_Printk
Signed-off-by: Michal Orzel
-
flight 187685 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187685/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a9b38305b64ef5997d0ba5f7d2797a75edd1f9ef
baseline version:
ovmf 6706fe6e239253e45b281
flight 187684 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187684/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6706fe6e239253e45b28147e06f71dd68a374007
baseline version:
ovmf bb403511d412959aaa373
On 2024/9/12 18:51, Jan Beulich wrote:
> On 12.09.2024 12:34, Daniel P. Smith wrote:
>> On 9/11/24 02:58, Jiqian Chen wrote:
>>> @@ -237,6 +238,34 @@ long arch_do_domctl(
>>> break;
>>> }
>>>
>>> +case XEN_DOMCTL_gsi_permission:
>>> +{
>>> +int irq;
>>> +u
flight 187682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187682/
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 187674 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187674/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 10 host-ping-check-xen fail REGR. vs. 187566
Tests which did not succeed, b
flight 187683 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187683/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb403511d412959aaa3733a8235257190d63b3ad
baseline version:
ovmf 8f74b95a21cf106fa4eb4
flight 187673 qemu-mainline real [real]
flight 187681 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187673/
http://logs.test-lab.xenproject.org/osstest/logs/187681/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
On Thu, 12 Sep 2024, Jan Beulich wrote:
> On 12.09.2024 03:05, Stefano Stabellini wrote:
> > On Tue, 10 Sep 2024, Jan Beulich wrote:
> >> On 10.09.2024 12:17, Nicola Vetrini wrote:
> >>> On 2024-09-10 12:03, Jan Beulich wrote:
> On 10.09.2024 11:53, Nicola Vetrini wrote:
> > On 2024-09-10
On Thu, 12 Sep 2024, Bertrand Marquis wrote:
> Hi Andrei,
>
> > On 11 Sep 2024, at 23:05, Andrei Cherechesu
> > wrote:
> >
> > Hi Julien, Stefano,
> > On 11/09/2024 08:19, Stefano Stabellini wrote:
> >> On Tue, 10 Sep 2024, Julien Grall wrote:
> >>
> >>> Hi,
> >>>
> >>> On 10/09/2024 15:34,
On Thu, 12 Sep 2024, Jan Beulich wrote:
> On 12.09.2024 03:13, Stefano Stabellini wrote:
> > On Tue, 10 Sep 2024, Jan Beulich wrote:
> >> On 10.09.2024 06:57, Stefano Stabellini wrote:
> >>> On Mon, 9 Sep 2024, Jan Beulich wrote:
> On 05.09.2024 17:48, Alessandro Zucchelli wrote:
> > This
flight 187679 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187679/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8f74b95a21cf106fa4eb4932e22b404c57297ba2
baseline version:
ovmf fe6b6feca7b6012278a43
The microcode might come from a questionable source, so it is necessary
for the parsers to treat it as untrusted. The CPU will validate the
microcode before applying it, so loading microcode from unofficial
sources is actually a legitimate thing to do in some cases.
Signed-off-by: Demi Marie Oben
On Thu, Sep 12, 2024 at 07:44:05PM +0100, Andrew Cooper wrote:
> On 12/09/2024 6:39 pm, Demi Marie Obenour wrote:
> > The microcode might come from a questionable source, so it is necessary
> > for the parsers to treat it as untrusted. The CPU will validate the
> > microcode before applying it, so
flight 187678 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187678/
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 Thu, 12 Sep 2024, Jan Beulich wrote:
> On 12.09.2024 10:57, Sergiy Kibrik wrote:
> > Introduce config option X86_STDVGA so that stdvga driver can be disabled on
> > systems that don't need it.
> >
> > Signed-off-by: Sergiy Kibrik
>
> Considering what was committed earlier in the day (and what
On 12/09/2024 7:44 pm, Andrew Cooper wrote:
> On 12/09/2024 6:39 pm, Demi Marie Obenour wrote:
>> Signed-off-by: Demi Marie Obenour
>> ---
>> xen/arch/x86/cpu/microcode/amd.c | 1 +
>> xen/arch/x86/cpu/microcode/intel.c | 5 +++--
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff -
On 12/09/2024 6:39 pm, Demi Marie Obenour wrote:
> The microcode might come from a questionable source, so it is necessary
> for the parsers to treat it as untrusted. The CPU will validate the
> microcode before applying it, so loading microcode from unofficial
> sources is actually a legitimate t
The microcode might come from a questionable source, so it is necessary
for the parsers to treat it as untrusted. The CPU will validate the
microcode before applying it, so loading microcode from unofficial
sources is actually a legitimate thing to do in some cases.
Signed-off-by: Demi Marie Oben
flight 187675 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187675/
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 187666 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187666/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187658
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, 2024-09-10 at 12:33 +0200, Jan Beulich wrote:
> > +/*
> > + * Mapping between linux logical cpu index and hartid.
> > + */
> > +#define cpuid_to_hartid(cpu) (pcpu_info[cpu].hart_id)
>
> Does this need to be a macro (rather than an inline function)?
I started to rework that and I am using t
Hi Michal,
> On 4 Sep 2024, at 1:43 PM, Michal Orzel wrote:
>
> SMR masking support allows deriving a mask either using a 2-cell iommu
> specifier (per master) or stream-match-mask SMMU dt property (global
> config). Even though the mask is stored in the fwid when adding a
> device (in arm_smmu
On Thu, Sep 12, 2024 at 05:38:17PM +0200, Jan Beulich wrote:
> Clang dislikes the boolean type combined with the field being set using
> PTF_partial_set.
>
> Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On 12/09/2024 4:38 pm, Jan Beulich wrote:
> Clang dislikes the boolean type combined with the field being set using
> PTF_partial_set.
>
> Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On Thu, Sep 12, 2024 at 4:38 PM Jan Beulich wrote:
>
> Clang dislikes the boolean type combined with the field being set using
> PTF_partial_set.
>
> Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/
On 11.09.2024 12:04, Oleksii Kurochko wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
> obj-$(CONFIG_CORE_PARKING) += core_parking.o
> obj-y += cpu.o
> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
> +obj-$(call or,$(CONFIG
Clang dislikes the boolean type combined with the field being set using
PTF_partial_set.
Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -286,7 +286,7 @@ struct page_info
s
On 11.09.2024 12:04, Oleksii Kurochko wrote:
> Introduce a new `.dev.info` section in the RISC-V linker script to
> handle device-specific information.
> This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
> marking the start and end of the section, respectively.
>
> Signed-
flight 187676 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187676/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fe6b6feca7b6012278a432226a56f0836ad1c457
baseline version:
ovmf 1197fb3383ddbe53d764c
On Thu, Sep 12, 2024 at 05:13:04PM +0200, Jan Beulich wrote:
> On 12.09.2024 17:08, Roger Pau Monné wrote:
> > On Thu, Sep 12, 2024 at 04:30:29PM +0200, Jan Beulich wrote:
> >> On 12.09.2024 14:52, GitLab wrote:
> >>>
> >>>
> >>> Pipeline #1450753094 has failed!
> >>>
> >>> Project: xen ( https://g
On 12.09.2024 17:08, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 04:30:29PM +0200, Jan Beulich wrote:
>> On 12.09.2024 14:52, GitLab wrote:
>>>
>>>
>>> Pipeline #1450753094 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging (
>>> https://gitla
On Thu, Sep 12, 2024 at 04:30:29PM +0200, Jan Beulich wrote:
> On 12.09.2024 14:52, GitLab wrote:
> >
> >
> > Pipeline #1450753094 has failed!
> >
> > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > Branch: staging (
> > https://gitlab.com/xen-project/hardware/xen/-/commits/sta
On 12.09.2024 17:03, Frediano Ziglio wrote:
> On Thu, Sep 12, 2024 at 3:35 PM Jan Beulich wrote:
>>
>> On 12.09.2024 03:13, Stefano Stabellini wrote:
>>> On Tue, 10 Sep 2024, Jan Beulich wrote:
On 10.09.2024 06:57, Stefano Stabellini wrote:
> On Mon, 9 Sep 2024, Jan Beulich wrote:
>>
On Thu, Sep 12, 2024 at 3:35 PM Jan Beulich wrote:
>
> On 12.09.2024 03:13, Stefano Stabellini wrote:
> > On Tue, 10 Sep 2024, Jan Beulich wrote:
> >> On 10.09.2024 06:57, Stefano Stabellini wrote:
> >>> On Mon, 9 Sep 2024, Jan Beulich wrote:
> On 05.09.2024 17:48, Alessandro Zucchelli wrote:
On 12.09.2024 03:13, Stefano Stabellini wrote:
> On Tue, 10 Sep 2024, Jan Beulich wrote:
>> On 10.09.2024 06:57, Stefano Stabellini wrote:
>>> On Mon, 9 Sep 2024, Jan Beulich wrote:
On 05.09.2024 17:48, Alessandro Zucchelli wrote:
> This section explains which format should be followed by
On 12/09/2024 3:23 pm, Jan Beulich wrote:
> On 12.09.2024 16:22, Andrew Cooper wrote:
>> On 12/09/2024 3:20 pm, Jan Beulich wrote:
>>> On 12.09.2024 14:51, Andrew Cooper wrote:
@@ -596,6 +594,8 @@ int __init iommu_setup(void)
}
else
{
+register_keyhan
On 12.09.2024 14:52, GitLab wrote:
>
>
> Pipeline #1450753094 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: 221f2748 (
> https://gitlab.com/xen-project/hardware/xen
On 12.09.2024 16:22, Andrew Cooper wrote:
> On 12/09/2024 3:20 pm, Jan Beulich wrote:
>> On 12.09.2024 14:51, Andrew Cooper wrote:
>>> @@ -596,6 +594,8 @@ int __init iommu_setup(void)
>>> }
>>> else
>>> {
>>> +register_keyhandler('o', &iommu_dump_page_tables, "dump iommu page
On 12/09/2024 3:20 pm, Jan Beulich wrote:
> On 12.09.2024 14:51, Andrew Cooper wrote:
>> @@ -596,6 +594,8 @@ int __init iommu_setup(void)
>> }
>> else
>> {
>> +register_keyhandler('o', &iommu_dump_page_tables, "dump iommu page
>> tables", 0);
>> +
>> if ( iommu_quar
On 12.09.2024 14:51, Andrew Cooper wrote:
> @@ -596,6 +594,8 @@ int __init iommu_setup(void)
> }
> else
> {
> +register_keyhandler('o', &iommu_dump_page_tables, "dump iommu page
> tables", 0);
> +
> if ( iommu_quarantine_init() )
> panic("Could not set
On Thu, Sep 12, 2024 at 03:47:53PM +0200, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 03:30:29PM +0200, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 12, 2024 at 02:56:55PM +0200, Roger Pau Monné wrote:
> > > On Thu, Sep 12, 2024 at 01:57:00PM +0200, Jan Beulich wrote:
> > > > On 12.09.202
On 12.09.2024 14:28, Frediano Ziglio wrote:
> On Thu, Sep 12, 2024 at 1:20 PM Jan Beulich wrote:
> Minor for the subject, there are also some removal of u64 and u8, not only s64
Right, which is being said ...
>> ... and move the type itself to linux-compat.h.
>>
>> While doing so
>> - correct th
On 12/09/2024 2:37 pm, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 01:51:54PM +0100, Andrew Cooper wrote:
>> All registration is done at boot. Almost...
>>
>> iommu_dump_page_tables() is registered in iommu_hwdom_init(), which is called
>> twice when LATE_HWDOM is in use.
>>
>> register_irq_k
On Thu, Sep 12, 2024 at 03:30:29PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 12, 2024 at 02:56:55PM +0200, Roger Pau Monné wrote:
> > On Thu, Sep 12, 2024 at 01:57:00PM +0200, Jan Beulich wrote:
> > > On 12.09.2024 13:15, Roger Pau Monne wrote:
> > > > --- a/xen/arch/x86/time.c
> > > >
On Thu, Sep 12, 2024 at 01:51:54PM +0100, Andrew Cooper wrote:
> All registration is done at boot. Almost...
>
> iommu_dump_page_tables() is registered in iommu_hwdom_init(), which is called
> twice when LATE_HWDOM is in use.
>
> register_irq_keyhandler() has an ASSERT() guarding againt multiple
On Thu, Sep 12, 2024 at 02:56:55PM +0200, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 01:57:00PM +0200, Jan Beulich wrote:
> > On 12.09.2024 13:15, Roger Pau Monne wrote:
> > > --- a/xen/arch/x86/time.c
> > > +++ b/xen/arch/x86/time.c
> > > @@ -1552,6 +1552,35 @@ static const char *__init
> >
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 26e7d8dd2ac4..8864ea7eafad 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -9,6 +9,7 @@ The format is based on [Keep a
Changelog](http
On 12/09/2024 1:20 pm, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so
> - correct the type of union uu's uq field in lib/divmod.c,
> - switch a few adjacent types as well, for (a little bit of)
> consistency.
>
> Signed-off-by: Jan Beulich
Reviewed-by: A
On Thu, Sep 12, 2024 at 01:57:00PM +0200, Jan Beulich wrote:
> On 12.09.2024 13:15, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -1552,6 +1552,35 @@ static const char *__init
> > wallclock_type_to_string(void)
> > return "";
> > }
> >
> > +stati
On 12/09/2024 1:50 pm, Roger Pau Monné wrote:
> On Thu, Sep 12, 2024 at 02:06:23PM +0200, Jan Beulich wrote:
>> On 12.09.2024 11:57, Roger Pau Monne wrote:
>>> Current blkif implementations (both backends and frontends) have all slight
>>> differences about how they handle the 'sector-size' xenstor
On 12/09/2024 1:19 pm, Jan Beulich wrote:
> Instead of replacing the s64 (and later also u64) uses, keep the file as
> little modified as possible from its Linux origin. (Sadly the two cast
> adjustments are needed to avoid compiler warnings.)
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan B
All registration is done at boot. Almost...
iommu_dump_page_tables() is registered in iommu_hwdom_init(), which is called
twice when LATE_HWDOM is in use.
register_irq_keyhandler() has an ASSERT() guarding againt multiple
registration attempts, and the absence of bug reports hints at how many
co
On Thu, Sep 12, 2024 at 02:06:23PM +0200, Jan Beulich wrote:
> On 12.09.2024 11:57, Roger Pau Monne wrote:
> > Current blkif implementations (both backends and frontends) have all slight
> > differences about how they handle the 'sector-size' xenstore node, and how
> > other fields are derived from
On Thu, Sep 12, 2024 at 1:20 PM Jan Beulich wrote:
>
Minor for the subject, there are also some removal of u64 and u8, not only s64
> ... and move the type itself to linux-compat.h.
>
> While doing so
> - correct the type of union uu's uq field in lib/divmod.c,
> - switch a few adjacent types as
... and move the type itself to linux-compat.h.
While doing so
- correct the type of union uu's uq field in lib/divmod.c,
- switch a few adjacent types as well, for (a little bit of)
consistency.
Signed-off-by: Jan Beulich
---
v2: Split off ubsan.[ch] adjustments. Re-base.
--- a/xen/arch/arm/
On 12/09/2024 1:10 pm, Jan Beulich wrote:
> On 12.09.2024 14:06, Andrew Cooper wrote:
>> stdvga_mem_accept() is called on almost all IO emulations, and the
>> overwhelming likely answer is to reject the ioreq. Simply rearranging the
>> expression yields an improvement:
>>
>> add/remove: 0/0 grow
Instead of replacing the s64 (and later also u64) uses, keep the file as
little modified as possible from its Linux origin. (Sadly the two cast
adjustments are needed to avoid compiler warnings.)
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/common/ubsan/ubsan.c
1: ubsan: use linux-compat.h
2: types: replace remaining uses of s64
Jan
On 12.09.2024 14:06, Andrew Cooper wrote:
> stdvga_mem_accept() is called on almost all IO emulations, and the
> overwhelming likely answer is to reject the ioreq. Simply rearranging the
> expression yields an improvement:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-57 (-57)
> Function
On 12.09.2024 11:57, Roger Pau Monne wrote:
> Current blkif implementations (both backends and frontends) have all slight
> differences about how they handle the 'sector-size' xenstore node, and how
> other fields are derived from this value or hardcoded to be expressed in units
> of 512 bytes.
>
stdvga_mem_accept() is called on almost all IO emulations, and the
overwhelming likely answer is to reject the ioreq. Simply rearranging the
expression yields an improvement:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-57 (-57)
Function old new delta
On 12.09.2024 13:15, Roger Pau Monne wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1552,6 +1552,35 @@ static const char *__init
> wallclock_type_to_string(void)
> return "";
> }
>
> +static int __init cf_check parse_wallclock(const char *arg)
> +{
> +if ( !arg )
flight 187671 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187671/
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 Thu, 2024-09-12 at 13:15 +0200, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-09-11 at 13:49 +0200, Jan Beulich wrote:
> > On 11.09.2024 13:34, oleksii.kuroc...@gmail.com wrote:
> > > On Tue, 2024-09-10 at 18:05 +0200, Jan Beulich wrote:
> > > > On 10.09.2024 17:28, oleksii.kuroc...@gmail.com
On Wed, 2024-09-11 at 13:49 +0200, Jan Beulich wrote:
> On 11.09.2024 13:34, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-09-10 at 18:05 +0200, Jan Beulich wrote:
> > > On 10.09.2024 17:28, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-09-10 at 11:53 +0200, Jan Beulich wrote:
> > > >
Hello,
This series started as an attempt to change the default wallclock
preference from EFI_GET_TIME to CMOS RTC, but has grown quite a lot.
Thanks, Roger.
Roger Pau Monne (2):
x86/time: introduce command line option to select wallclock
x86/time: prefer CMOS over EFI_GET_TIME
docs/misc/xe
The EFI_GET_TIME implementation is well known to be broken for many firmware
implementations, for Xen the result on such implementations are:
[ Xen-4.19-unstable x86_64 debug=y Tainted: C]
CPU:0
RIP:e008:[<62ccfa70>] 62ccfa70
[...]
Xen call trace:
[<
Allow setting the used wallclock from the command line. When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).
The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported bu
On 12/09/24 12:01, Jan Beulich wrote:
On 12.09.2024 11:17, Federico Serafini wrote:
On 11/09/24 14:42, Jan Beulich wrote:
On 10.09.2024 12:09, Federico Serafini wrote:
--- a/xen/arch/x86/x86_emulate/fpu.c
+++ b/xen/arch/x86/x86_emulate/fpu.c
@@ -218,6 +218,7 @@ int x86emul_fpu(struct x86_emula
On Thu, Sep 12, 2024 at 12:05:23PM +0200, Jan Beulich wrote:
> On 12.09.2024 11:52, Roger Pau Monné wrote:
> > On Thu, Aug 29, 2024 at 02:01:16PM +0200, Jan Beulich wrote:
> >> ... and move the type itself to linux-compat.h.
> >>
> >> While doing so switch a few adjacent types as well, for (a littl
On 2024-09-12 12:20, Jan Beulich wrote:
On 12.09.2024 10:12, GitLab wrote:
Pipeline #1450299635 has failed!
Project: xen ( https://gitlab.com/xen-project/hardware/xen )
Branch: staging (
https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
Commit: 6e7f7a0c (
https://gitlab.com/
flight 187672 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187672/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1197fb3383ddbe53d764cb9b3583c1738ac62a18
baseline version:
ovmf babccb841dbb39de2b448
On 12.09.2024 12:34, Daniel P. Smith wrote:
> On 9/11/24 02:58, Jiqian Chen wrote:
>> @@ -237,6 +238,34 @@ long arch_do_domctl(
>> break;
>> }
>>
>> +case XEN_DOMCTL_gsi_permission:
>> +{
>> +int irq;
>> +unsigned int gsi = domctl->u.gsi_permission.gsi;
>>
Greetings!
On 9/11/24 02:58, Jiqian Chen wrote:
Some domains are not aware of the pIRQ abstraction layer that maps
interrupt sources into Xen space interrupt numbers. pIRQs values are
only exposed to domains that have the option to route physical
interrupts over event channels.
This creates is
On 12.09.2024 10:57, Sergiy Kibrik wrote:
> Introduce config option X86_STDVGA so that stdvga driver can be disabled on
> systems that don't need it.
>
> Signed-off-by: Sergiy Kibrik
Considering what was committed earlier in the day (and what you would have
seen on the list already before that)
On 12/09/2024 11:11 am, Jan Beulich wrote:
> On 12.09.2024 10:12, GitLab wrote:
>>
>> Pipeline #1450299635 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging (
>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: 6e7f7a0c (
On 12.09.2024 10:12, GitLab wrote:
>
>
> Pipeline #1450299635 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: 6e7f7a0c (
> https://gitlab.com/xen-project/hardware/xen
On 12.09.2024 10:12, GitLab wrote:
>
>
> Pipeline #1450299635 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: 6e7f7a0c (
> https://gitlab.com/xen-project/hardware/xen
On Thu Sep 12, 2024 at 10:49 AM BST, Andrew Cooper wrote:
> On 11/09/2024 3:58 pm, Alejandro Vallejo wrote:
> > diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> > index b8482de8ee..ef803f6288 100644
> > --- a/xen/arch/x86/x86_64/entry.S
> > +++ b/xen/arch/x86/x86_64/entry.S
On 12.09.2024 11:52, Roger Pau Monné wrote:
> On Thu, Aug 29, 2024 at 02:01:16PM +0200, Jan Beulich wrote:
>> ... and move the type itself to linux-compat.h.
>>
>> While doing so switch a few adjacent types as well, for (a little bit
>> of) consistency.
>>
>> Signed-off-by: Jan Beulich
>
> Review
On 12.09.2024 11:17, Federico Serafini wrote:
> On 11/09/24 14:42, Jan Beulich wrote:
>> On 10.09.2024 12:09, Federico Serafini wrote:
>>> --- a/xen/arch/x86/x86_emulate/fpu.c
>>> +++ b/xen/arch/x86/x86_emulate/fpu.c
>>> @@ -218,6 +218,7 @@ int x86emul_fpu(struct x86_emulate_state *s,
>>>
On Thu, Aug 29, 2024 at 02:00:20PM +0200, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so switch an adjacent x86 struct page_info field to bool.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On 12.09.2024 11:27, oleksii.kuroc...@gmail.com wrote:
> As I mentioned above, interrupts will be disabled until tp is set.
Okay, so all good then
> Even
> if they aren’t disabled, tp will be set to 0 because, at the moment the
> secondary CPU boots, CSR_SSCRATCH will be 0, which indicates that t
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.
To give some context, this is an excerpt of how differ
On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> Individual subsystems ought not to know or care about XENPV; it's a
> layering violation.
Agreed.
> If the main APIs don't behave properly, then it probably means we've got
> a bug at a lower level (e.g. Xen SWIOTLB is a constant so
On Thu, Aug 29, 2024 at 02:01:16PM +0200, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so switch a few adjacent types as well, for (a little bit
> of) consistency.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On 11/09/2024 3:58 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index b8482de8ee..ef803f6288 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -844,8 +844,7 @@ handle_exception_saved:
> #elif !defined(CONF
09.09.24 17:28, Jan Beulich:
--- a/xen/arch/x86/include/asm/cpuidle.h
+++ b/xen/arch/x86/include/asm/cpuidle.h
@@ -15,7 +15,14 @@ extern void (*lapic_timer_on)(void);
extern uint64_t (*cpuidle_get_tick)(void);
+#ifdef CONFIG_INTEL
int mwait_idle_init(struct notifier_block *nfb);
+#else
On Wed, Sep 11, 2024 at 03:58:23PM +0100, Alejandro Vallejo wrote:
> Moves sti directly after the cr2 read and immediately after the #PF
> handler.
>
> While in the area, remove redundant q suffix to a movq in entry.S
>
> Signed-off-by: Alejandro Vallejo
> ---
> I don't think this is a bug as mu
Hi Daniel,
On 2024/9/11 14:58, Chen, Jiqian wrote:
> Some domains are not aware of the pIRQ abstraction layer that maps
> interrupt sources into Xen space interrupt numbers. pIRQs values are
> only exposed to domains that have the option to route physical
> interrupts over event channels.
>
> Th
On Tue, Sep 10, 2024 at 04:01:50PM +0200, Jürgen Groß wrote:
> On 10.09.24 15:59, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 03:46:00PM +0200, Jürgen Groß wrote:
> > > On 10.09.24 13:46, Roger Pau Monne wrote:
> > > > diff --git a/xen/include/public/io/blkif.h
> > > > b/xen/include/public/
09.09.24 17:24, Jan Beulich:
On 03.09.2024 09:26, Sergiy Kibrik wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -284,6 +284,9 @@ endchoice
config GUEST
bool
+config PSR
+ bool
+
config XEN_GUEST
bool "Xen Guest"
select GUEST
Inserting in th
On Wed, Sep 11, 2024 at 02:58:32PM +0800, Jiqian Chen wrote:
> When dom0 is PVH, and passthrough a device to dumU, xl will
> use the gsi number of device to do a pirq mapping, see
> pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is
> got from file /sys/bus/pci/devices//irq, that confuses
flight 187663 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187663/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-vhd 22 leak-check/check fail like 187657
test-amd64-amd64-xl-qemuu-win7-amd6
On Wed, 2024-09-11 at 14:14 +0200, Jan Beulich wrote:
> On 11.09.2024 14:05, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-09-10 at 12:33 +0200, Jan Beulich wrote:
> > > On 02.09.2024 19:01, Oleksii Kurochko wrote:
> > > > @@ -72,6 +77,16 @@ FUNC(reset_stack)
> > > > ret
> > > > END(
1 - 100 of 111 matches
Mail list logo
