flight 185872 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185872/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 8 xen-boot fail pass in 185860
Tests which did not succeed,
flight 185871 linux-6.1 real [real]
flight 185889 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185871/
http://logs.test-lab.xenproject.org/osstest/logs/185889/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 185870 linux-linus real [real]
flight 185887 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185870/
http://logs.test-lab.xenproject.org/osstest/logs/185887/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Henry,
On 30/04/2024 04:50, Henry Wang wrote:
On 4/25/2024 10:28 PM, Julien Grall wrote:
Thanks for your feeedback. After checking the b8577547236f commit
message I think I now understand your point. Do you have any
suggestion about how can I properly add the support to route/remove
the
Update it to get XENFEAT_dm_msix_all_writes for the next patch.
Signed-off-by: Marek Marczykowski-Górecki
---
include/hw/xen/interface/features.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/hw/xen/interface/features.h
b/include/hw/xen/interface/features.h
The /dev/mem is used for two purposes:
- reading PCI_MSIX_ENTRY_CTRL_MASKBIT
- reading Pending Bit Array (PBA)
The first one was originally done because when Xen did not send all
vector ctrl writes to the device model, so QEMU might have outdated old
register value. If Xen is new enough, this
Call pci_default_write_config() in xen_pt_pci_write_config() only for
registers that have matching XenPTRegInfo structure, and do that only after
resolving any custom handlers. This is important for two reasons:
1. XenPTRegInfo has ro_mask which needs to be enforced - Xen-specific
hooks do that
Iterate over the p2m based on the maximum recorded gfn and remove any foreign
mappings, in order to drop the underlying page references and thus don't keep
extra page references if a domain is destroyed while still having foreign
mappings on it's p2m.
The logic is similar to the one used on Arm.
Hello,
The following series attempts to solve a shortcoming of HVM/PVH guests
with the lack of support for foreign mappings. Such lack of support
prevents using PVH based guests as stubdomains for example.
Add support in a way similar to how it was done on Arm, by iterating
over the p2m based
Keep track of the maximum gfn that has ever been populated into the p2m, and
also account for the number of foreign mappings. Such information will be
needed in order to remove foreign mappings during teardown for HVM guests.
Right now the introduced counters are not consumed.
Signed-off-by:
flight 185880 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185880/
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
From: "Edgar E. Iglesias"
Propagate MR and is_write to xen_map_cache().
This is in preparation for adding support for grant mappings.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 10 ++
include/sysemu/xen-mapcache.h | 11 +++
From: "Edgar E. Iglesias"
Break out xen_invalidate_map_cache_single().
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/hw/xen/xen-mapcache.c
From: "Edgar E. Iglesias"
The current mapcache assumes that all memory is mapped
in a single RAM MR (the first one with offset 0). Remove
this assumption and propagate the offset to the mapcache
so it can do reverse mappings (from hostptr -> ram_addr).
This is in preparation for adding grant
From: "Edgar E. Iglesias"
Add MapCache argument to xen_remap_bucket in preparation
to support multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
From: "Edgar E. Iglesias"
Add MapCache argument to xen_replace_cache_entry_unlocked in
preparation for supporting multiple map caches.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
From: "Edgar E. Iglesias"
Make MCACHE_BUCKET_SHIFT runtime configurable per cache instance.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 52 ++-
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/hw/xen/xen-mapcache.c
From: Juergen Gross
Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
case it can't find a matching entry for a pointer value. Both cases
are bad, so change that to return an invalid address instead.
Signed-off-by: Juergen Gross
Signed-off-by: Edgar E. Iglesias
From: "Edgar E. Iglesias"
Add a second mapcache for grant mappings. The mapcache for
grants needs to work with XC_PAGE_SIZE granularity since
we can't map larger ranges than what has been granted to us.
Like with foreign mappings (xen_memory), machines using grants
are expected to initialize
From: "Edgar E. Iglesias"
Add xen_mr_is_memory() to abstract away tests for the
xen_memory MR.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-hvm-common.c | 8 +++-
include/sysemu/xen.h| 8
system/physmem.c| 2 +-
3 files changed, 16 insertions(+), 2 deletions(-)
From: "Edgar E. Iglesias"
When invalidating memory ranges, if we happen to hit the first
entry in a bucket we were never unmapping it. This was harmless
for foreign mappings but now that we're looking to reuse the
mapcache for transient grant mappings, we must unmap entries
when invalidated.
From: "Edgar E. Iglesias"
Make the lock functions take MapCache * as argument. This is
in preparation for supporting multiple caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 34 +-
1 file changed, 17 insertions(+),
From: "Edgar E. Iglesias"
Break out xen_map_cache_init_single() in preparation for
adding multiple map caches.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 53 ++-
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git
From: "Edgar E. Iglesias"
Break out xen_ram_addr_from_mapcache_single(), a multi-cache
aware version of xen_ram_addr_from_mapcache.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff
From: "Edgar E. Iglesias"
Add MapCache argument to xen_invalidate_map_cache_entry_unlocked.
This is in preparation for supporting multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 21 +++--
1 file changed, 11
From: "Edgar E. Iglesias"
Make xen_map_cache take a MapCache as argument. This is in
prepaparation to support multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 35 ++-
1 file changed, 18 insertions(+), 17
Hi Jan,
From: Hongyan Xia
Before, it assumed the pv cr3 could be accessed via a direct map. This
is no longer true.
There are a number of terminology issues here, starting with the title:
Unlike (iirc) in an earlier version, no mapping/unmapping occurs in
restore_all_guests itself anymore.
On Tue, Apr 30, 2024 at 4:27 PM Jan Beulich wrote:
>
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -685,6 +685,12 @@ int arch_sanitise_domain_config(struct
> > xen_domctl_createdomain *config)
> > return -EINVAL;
> > }
> >
> > +if ( config->max_altp2m >
On Tue, Apr 30, 2024 at 4:47 PM Jan Beulich wrote:
>
> On 28.04.2024 18:52, Petr Beneš wrote:
> > From: Petr Beneš
> >
> > This change anticipates scenarios where `max_altp2m` is set to its maximum
> > supported value (i.e., 512), ensuring sufficient memory is allocated upfront
> > to
None of the implementations support set_foreign_p2m_entry() yet, neither they
have a p2m walk in domain_relinquish_resources() in order to remove the foreign
mappings from the p2m and thus drop the extra refcounts.
Adjust the arch helpers to return false and introduce a comment that clearly
On 2024-04-30 17:13, Jan Beulich wrote:
On 30.04.2024 16:28, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that
all
On 30.04.2024 16:28, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 30.04.2024 16:28, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 26.04.2024 19:54, Marek Marczykowski-Górecki wrote:
> Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
> on the same page as MSI-X table. Device model (especially one in
> stubdomain) cannot really handle those, as direct writes to that page is
> refused (page is on the
On 26.04.2024 19:53, Marek Marczykowski-Górecki wrote:
> The arch_msix struct had a single "warned" field with a domid for which
> warning was issued. Upcoming patch will need similar mechanism for few
> more warnings, so change it to save a bit field of issued warnings.
>
> Signed-off-by: Marek
On 28.04.2024 18:52, Petr Beneš wrote:
> From: Petr Beneš
>
> This change anticipates scenarios where `max_altp2m` is set to its maximum
> supported value (i.e., 512), ensuring sufficient memory is allocated upfront
> to accommodate all altp2m tables without initialization failure.
And guests
On Wed, Feb 07, 2024 at 05:39:57PM +, Alejandro Vallejo wrote:
> diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
> index 5699a26b946e..cee0be80ba5b 100644
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -772,49 +616,45 @@ int
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted
On 28.04.2024 18:52, Petr Beneš wrote:
> From: Petr Beneš
>
> This commit introduces the ability to configure the maximum number of altp2m
> tables during domain creation. Previously, the limits were hardcoded to a
> maximum of 10. This change allows for greater flexibility in environments that
On Wed, Feb 07, 2024 at 05:39:56PM +, Alejandro Vallejo wrote:
> The idea is to use xc_cpu_policy_t as a single object containing both the
> serialised and deserialised forms of the policy. Note that we need lengths
> for the arrays, as the serialised policies may be shorter than the array
>
On Wed, Feb 07, 2024 at 05:39:55PM +, Alejandro Vallejo wrote:
> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
> index e01f494b772a..4e9078fdee4d 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -784,7 +784,13 @@ xen_pfn_t
On 29.04.2024 17:16, Andrew Cooper wrote:
> For display purposes only right now.
And limited to a narrow subset, presumably intentionally.
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Jan
On 30.04.2024 15:25, Andrew Cooper wrote:
> On 30/04/2024 1:45 pm, Jan Beulich wrote:
>> On 29.04.2024 17:16, Andrew Cooper wrote:
>>> Allocate two new feature leaves, and extend cpu_policy with the non-feature
>>> fields too.
>>>
>>> The CPUID dependency between the SVM bit on the whole SVM leaf
On 30/04/2024 1:45 pm, Jan Beulich wrote:
> On 29.04.2024 17:16, Andrew Cooper wrote:
>> Allocate two new feature leaves, and extend cpu_policy with the non-feature
>> fields too.
>>
>> The CPUID dependency between the SVM bit on the whole SVM leaf is
>> intentionally deferred, to avoid
On 29.04.2024 17:16, Andrew Cooper wrote:
> @@ -2493,38 +2491,14 @@ const struct hvm_function_table * __init
> start_svm(void)
>
> setup_vmcb_dump();
>
> -if ( boot_cpu_data.extended_cpuid_level >= 0x800aU )
> -svm_feature_flags = cpuid_edx(0x800aU);
> -
> -
flight 185879 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185879/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5d4c5253e8bbc0baa8837fcd868925212df85201
baseline version:
ovmf
On 29.04.2024 17:16, Andrew Cooper wrote:
> Now that the SVM feature leaf has been included in normal feature handling, it
> is available early enough for init_speculation_mitigations() to use.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
even if ...
>
On 29.04.2024 17:16, Andrew Cooper wrote:
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -358,6 +358,20 @@ XEN_CPUFEATURE(RFDS_CLEAR, 16*32+28) /*!A
> Register File(s) cleared by VE
> /* Intel-defined CPU features,
flight 185867 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185867/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185710
On Tue, Apr 30, 2024 at 02:06:38PM +0200, Jan Beulich wrote:
> On 30.04.2024 13:25, Roger Pau Monné wrote:
> > On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
> >> On 30.04.2024 10:29, Roger Pau Monne wrote:
> >>> static const struct {
> >>> const char *name;
> >>> const
On 2024-04-30 13:09, Luca Fancellu wrote:
Commit 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
bank structures") introduced a MISRA regression for Rule 1.1 because a
flexible array member is introduced in the middle of a struct,
furthermore
this is using a GCC extension that
Refactor microcode_update() by adding a flags field.
struct xenpf_microcode_update2 added with uint32_t flags field.
Introduce XENPF_microcode_update2 hypercall to handle flags field.
Introduce ucode_force_flag to microcode_update_helper.
Signed-off-by: Fouad Hilly
---
[v3]
1- Updated Commit
Refactor xen-ucode tool by adding usage() to handle usage\help messages.
As we add more command options this will keep help\usage messages in a common
block.
Only generic error message is printed to stderr. usage and show_curr_cpu are
printed to stdout.
Signed-off-by: Fouad Hilly
---
[v3]
1-
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
This change is required to enable developers to load ucode that is
Introduce --force option to xen-ucode to force skipping microcode version
check, which allows the user to update x86 microcode even if both versions
are the same.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2
Signed-off-by: Fouad Hilly
Suggested-by:
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
Signed-off-by: Fouad Hilly
---
[v3]
1- Exit with error prints erros only to stderr.
2- Remove argc checks.
3- Utilize optind.
[v2]
1- Removed unnecessary NULL initialization.
2- Used static at the
Update microcode version check at Intel and AMD Level by:
Preventing the low level code from sending errors if the microcode
version is not a newer version. this is required to allow developers to do
ucode loading testing, including the introduction of Intel "min rev" field,
which requires an
On 29.04.2024 17:16, Andrew Cooper wrote:
> Allocate two new feature leaves, and extend cpu_policy with the non-feature
> fields too.
>
> The CPUID dependency between the SVM bit on the whole SVM leaf is
> intentionally deferred, to avoid transiently breaking nested virt.
In reply to this I
On 29.04.2024 15:42, Matthew Barnes wrote:
> When the evtchn_status hypercall fails, it is not possible to determine
> the cause of the error, since the library call returns -1 to the tool
> and not the errno.
That's normal behavior for such library functions. If you want to know the
specific
On 30.04.2024 13:25, Roger Pau Monné wrote:
> On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
>> On 30.04.2024 10:29, Roger Pau Monne wrote:
>>> static const struct {
>>> const char *name;
>>> const char *abbr;
>>> -const char *const *strs;
>>
>> While how you're doing
On 30.04.2024 13:09, Luca Fancellu wrote:
> --- a/xen/include/xen/kernel.h
> +++ b/xen/include/xen/kernel.h
> @@ -54,6 +54,27 @@
> typeof_field(type, member) *__mptr = (ptr); \
> (type *)( (char *)__mptr - offsetof(type,member) );})
>
> +/**
> + * __struct_group() -
On 30.04.2024 13:09, Luca Fancellu wrote:
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -64,18 +64,20 @@ struct membank {
> };
>
> struct membanks {
> -unsigned int nr_banks;
> -unsigned int max_banks;
> +__struct_group(membanks_hdr, common,
On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
> On 30.04.2024 10:29, Roger Pau Monne wrote:
> > Like it was done recently for libxl, switch to using the auto-generated
> > feature
> > names by the processing of cpufeatureset.h, this allows removing the
> > open-coded
> > feature
flight 185875 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185875/
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
Import __struct_group from Linux, commit 50d7bd38c3aa
("stddef: Introduce struct_group() helper macro"), in order to
allow the access through the anonymous structure to the members
without having to write also the name, e.g:
struct foo {
int one;
struct {
int two;
int
This small serie is fixing a MISRA regression on the R1.1 due to the
introduction of a new interface that uses a flexible member array [1].
I've splitted the serie in two in order to keep the Linux imported code on a
single commit, the imported macro is later used in the second patch of the
Commit 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
bank structures") introduced a MISRA regression for Rule 1.1 because a
flexible array member is introduced in the middle of a struct, furthermore
this is using a GCC extension that is going to be deprecated in GCC 14 and
a
On 30.04.2024 10:29, Roger Pau Monne wrote:
> Like it was done recently for libxl, switch to using the auto-generated
> feature
> names by the processing of cpufeatureset.h, this allows removing the
> open-coded
> feature names, and unifies the feature naming with libxl and the hypervisor.
>
>
On 4/29/24 22:55, Henry Wang wrote:
Hi Daniel,
On 4/30/2024 8:27 AM, Daniel P. Smith wrote:
On 4/25/24 23:14, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after
On 30.04.2024 11:58, Andrew Cooper wrote:
> On 30/04/2024 10:00 am, Jan Beulich wrote:
>> On 30.04.2024 10:03, GitLab wrote:
>>>
>>> Pipeline #1272869158 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging (
>>>
On 30/04/2024 10:00 am, Jan Beulich wrote:
> On 30.04.2024 10:03, GitLab wrote:
>>
>> Pipeline #1272869158 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging (
>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: b819bd65
flight 185866 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185866/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 185709
On 30/04/2024 05:00, Henry Wang wrote:
Hi Julien,
Hi Henry,
On 4/30/2024 1:34 AM, Julien Grall wrote:
On 29/04/2024 04:36, Henry Wang wrote:
Hi Jan, Julien, Stefano,
Hi Henry,
On 4/24/2024 2:05 PM, Jan Beulich wrote:
On 24.04.2024 05:34, Henry Wang wrote:
---
29.04.24 18:34, Jan Beulich:
On 23.04.2024 10:50, Sergiy Kibrik wrote:
Since MCG_LMCE_P bit is specific to Intel CPUs
That's the case now. It could change going forward, and an underlying hypervisor
might also have (obscure?) reasons to surface it elsewhere.
the code to check it can
flight 185876 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185876/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c74aa2073e48b2143413f2dc76557acf8884202
baseline version:
ovmf
On 30/04/24 11:00, Jan Beulich wrote:
On 30.04.2024 10:03, GitLab wrote:
Pipeline #1272869158 has failed!
Project: xen ( https://gitlab.com/xen-project/hardware/xen )
Branch: staging ( https://gitlab.com/xen-project/hardware/xen/-/commits/staging
)
Commit: b819bd65 (
On 22.04.2024 20:14, Andrew Cooper wrote:
> @@ -322,12 +334,9 @@
> ALTERNATIVE "", __stringify(DO_SPEC_CTRL_ENTRY maybexen=1), \
> X86_FEATURE_SC_MSR_PV
>
> -testb $SCF_entry_bhb, %bl
> -jz .L\@_skip_bhb
> -ALTERNATIVE_2 "",\
29.04.24 18:28, Jan Beulich:
Any reason you don't follow the approach used in patch 7, putting simple
#ifdef in the switch() in vpmu_init()? That would avoid the need for the
three almost identical stubs.
I didn't want to put that many preprocessor statements into this small
switch() block (4
On 30.04.2024 10:03, GitLab wrote:
>
>
> Pipeline #1272869158 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: b819bd65 (
>
On 30.04.2024 10:12, Henry Wang wrote:
> Hi Jan,
>
> On 4/30/2024 2:11 PM, Jan Beulich wrote:
>> On 30.04.2024 04:51, Henry Wang wrote:
>>> On 4/30/2024 8:31 AM, Daniel P. Smith wrote:
On 4/26/24 02:21, Jan Beulich wrote:
> On 26.04.2024 05:14, Henry Wang wrote:
>> ---
Like it was done recently for libxl, switch to using the auto-generated feature
names by the processing of cpufeatureset.h, this allows removing the open-coded
feature names, and unifies the feature naming with libxl and the hypervisor.
Note that leaf names need to be kept, as the current
Hi Jan,
On 4/30/2024 2:11 PM, Jan Beulich wrote:
On 30.04.2024 04:51, Henry Wang wrote:
On 4/30/2024 8:31 AM, Daniel P. Smith wrote:
On 4/26/24 02:21, Jan Beulich wrote:
On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@
On Mon, Apr 29, 2024 at 01:53:44PM +0200, Juergen Gross wrote:
> Hi,
>
> I'd like to dispute CVE-2024-26908: the issue fixed by upstream commit
> 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 can in no way be triggered by
> an unprivileged user or by a remote attack of the system, as it requires
>
On 24/04/24 14:38, Jan Beulich wrote:
On 24.04.2024 14:23, Federico Serafini wrote:
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings.
Amend an existing entry of Rule 14.4 in deviations.rst:
it is not a project-wide deviation.
Who / how is it not?
On 4/29/24 5:16 PM, Andrew Cooper wrote:
For display purposes only right now.
Signed-off-by: Andrew Cooper
Reviewed-by: Vaishali Thakkar
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Xenia Ragiadakou
CC: Sergiy Kibrik
CC: George Dunlap
CC: Andrei Semenov
CC:
On 30.04.2024 04:51, Henry Wang wrote:
> On 4/30/2024 8:31 AM, Daniel P. Smith wrote:
>> On 4/26/24 02:21, Jan Beulich wrote:
>>> On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -76,6 +76,7 @@
*/
89 matches
Mail list logo
