On 15.08.22 22:32, Stefano Stabellini wrote:
+ Xen maintainers and committers
For context, I wrote a patch to introduce SPDX tags starting from
arch/arm/*.c.
Don't we want something like the kernel's LICENSES directory in order to
have something the SPDX lines refer to? COPYING should maybe
flight 172546 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172546/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH 7/7] xen/arm32: traps: Dump more information for
> hypervisor data abort
> Hmmm... I dropped a patch from the series and it looks like I didn't
> properly clean the directory before doing that. Please ignore patch
flight 172552 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172552/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
When a static domain populates memory through populate_physmap at runtime,
it shall retrieve reserved pages from resv_page_list to make sure that
guest RAM is still restricted in statically configured memory regions.
This commit also introduces a new helper acquire_reserved_page to make it work.
Later, we want to use acquire_domstatic_pages() for populating memory
for static domain on runtime, however, there are a lot of pointless work
(checking mfn_valid(), scrubbing the free part, cleaning the cache...)
considering we know the page is valid and belong to the guest.
This commit splits
The name of free_staticmem_pages is inappropriate, considering it is
the opposite of function prepare_staticmem_pages.
Rename free_staticmem_pages to unprepare_staticmem_pages.
Signed-off-by: Penny Zheng
---
v10 changes:
- new commit
---
xen/arch/arm/setup.c| 3 ++-
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Acked-by: Jan Beulich
---
v10 changes:
The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the reserved pages to heap
allocator accidentally as a
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
This commit introduces a new helper free_domstatic_page to free
static page in
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain.
Pages used as guest RAM for static domain shall always be reserved to this
domain only, and not be used for any other purposes, so
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
v10
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
---
v10 changes:
-
flight 172543 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172543/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1
On Sat, 13 Aug 2022, Julien Grall wrote:
> Hi Stefano,
>
> On 13/08/2022 01:59, Stefano Stabellini wrote:
> > Add SPDX license information to all the *.c files under arch/arm.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >
> > We need to start from somewhere and I thought arch/arm/*.c
+ Xen maintainers and committers
For context, I wrote a patch to introduce SPDX tags starting from
arch/arm/*.c.
Julien rightfully pointed out that it should be added to our coding
style. He is right. Also as I was reading his replies, I realized there
are a couple of minor coding style things
flight 172538 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172535 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
On 15/08/2022 10:14, Jan Beulich wrote:
> On 15.08.2022 10:15, Andrew Cooper wrote:
>> On 15/08/2022 09:01, Jan Beulich wrote:
>>> On 17.05.2022 17:31, Roger Pau Monne wrote:
Roger Pau Monne (3):
amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
amd/msr: allow
On 8/15/2022 2:00 PM, Thorsten Leemhuis wrote:
> Hi Chuck!
>
> On 15.08.22 18:56, Chuck Zmudzinski wrote:
> >
> > I am forwarding this to you to help you cut through the noise.
>
> Sorry for not replying earlier, I ignored this thread and all other
> non-urgent mail in the past two weeks: I was
Hi Chuck!
On 15.08.22 18:56, Chuck Zmudzinski wrote:
>
> I am forwarding this to you to help you cut through the noise.
Sorry for not replying earlier, I ignored this thread and all other
non-urgent mail in the past two weeks: I was on vacation until a few
days ago and when I came home I had to
On 15/08/2022 17:39, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 12 Aug 2022, at 20:24, Julien Grall wrote:
From: Julien Grall
Unlike arm64, on arm32 there are no extra information dumped (e.g.
page table walk) for hypervisor data abort.
The code in arch/arm/traps.c has
Hi all,
Please ignore this patch. This is a duplication of patch #7.
Cheers,
On 12/08/2022 20:24, Julien Grall wrote:
From: Julien Grall
Unlike arm64, on arm32 there are no extra information dumped (e.g.
page table walk) for hypervisor data abort.
For data abort, the HSR will be set
On 15/08/2022 02:40, Henry Wang wrote:
Hi Julien,
Hi Henry,
-Original Message-
Subject: [PATCH 7/7] xen/arm32: traps: Dump more information for
hypervisor data abort
From: Julien Grall
Unlike arm64, on arm32 there are no extra information dumped (e.g.
page table walk) for
Hi Jan,
On 15/08/2022 09:21, Jan Beulich wrote:
On 15.08.2022 10:17, Julien Grall wrote:
On 15/08/2022 07:43, Jan Beulich wrote:
On 12.08.2022 21:24, Julien Grall wrote:
From: Julien Grall
At the moment, the strings are in text right after each use because
the instruction 'adr' has
On 15/08/2022 15:45, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 12 Aug 2022, at 20:24, Julien Grall wrote:
From: Julien Grall
There are a few places in the code that need to find the slot
at a given page-table level.
So create a new macro get_table_slot() for that. This will
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> Unlike arm64, on arm32 there are no extra information dumped (e.g.
> page table walk) for hypervisor data abort.
The code in arch/arm/traps.c has nothing arm32 specific like that so
could you explain this
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, the strings are in text right after each use because
> the instruction 'adr' has specific requirement on the location
> and the compiler will forbid cross section label.
>
> The macro 'adr_l'
On 15.08.2022 17:39, Dylanger Daly wrote:
> Great news! I managed to get it to log the error with your cmdlines
>
> Please see the attached images
>
> The error "BUG: unable to handle page fault for address: c90040639019"
>
> It appears to be a memory violation error?
Yes, there's an
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> Currently the output is looking like:
>
> (XEN) 1ST[0x1] = 0x4015ff7f
> (XEN) 2ND[0x1f] = 0x0050bfe00f7d
>
> The content of the entries are not aligned making a bit trickier to
> read (I
On 8/14/2022 9:01 AM, Greg KH wrote:
> On Sun, Aug 14, 2022 at 08:08:30AM -0400, Chuck Zmudzinski wrote:
> > On 8/14/2022 5:50 AM, Greg KH wrote:
> > > On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> > > > Well, that did not take long. Juergen responded with a message,
> > > >
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, the macro addr_l needs to know whether the caller
> is running with the MMU on. This is fine today because there are
> only two possible cases:
> 1) MMU off
> 2) MMU on and linked to the
On 15.08.22 17:20, Jan Beulich wrote:
On 15.08.2022 17:13, Juergen Gross wrote:
On 27.07.22 18:00, Jan Beulich wrote:
The initial observation were duplicate symbols that our checking warns
about. Instead of merely renaming one or both pair(s) of symbols,
reduce #ifdef-ary at the same time by
On 15.08.2022 16:58, Jason Andryuk wrote:
> On Mon, Aug 15, 2022 at 10:34 AM Jan Beulich wrote:
>>
>> On 10.08.2022 21:29, Jason Andryuk wrote:
>>> Export feature_detect as intel_feature_detect so it can be re-used by
>>> HWP.
>>>
>>> Signed-off-by: Jason Andryuk
>>> ---
>>> v2
>>> export
On 15.08.2022 17:13, Juergen Gross wrote:
> On 27.07.22 18:00, Jan Beulich wrote:
>> The initial observation were duplicate symbols that our checking warns
>> about. Instead of merely renaming one or both pair(s) of symbols,
>> reduce #ifdef-ary at the same time by moving the instantiation of the
flight 172544 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 27.07.22 18:00, Jan Beulich wrote:
The initial observation were duplicate symbols that our checking warns
about. Instead of merely renaming one or both pair(s) of symbols,
reduce #ifdef-ary at the same time by moving the instantiation of the
arrays into macros (a native and a 32-bit one each,
On Mon, Aug 15, 2022 at 10:34 AM Jan Beulich wrote:
>
> On 10.08.2022 21:29, Jason Andryuk wrote:
> > Export feature_detect as intel_feature_detect so it can be re-used by
> > HWP.
> >
> > Signed-off-by: Jason Andryuk
> > ---
> > v2
> > export intel_feature_detect with typed pointer
> > Move
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> There are a few places in the code that need to find the slot at a
> given page-table level.
>
> So create a new macro get_table_slot() for that. This will reduce
> the effort to figure out whether the code
flight 172532 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172532/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On Mon, Aug 15, 2022 at 10:22 AM Jan Beulich wrote:
>
> On 10.08.2022 21:29, Jason Andryuk wrote:
> > For hwp, the standard governors are not usable, and only the internal
> > one is applicable. Add the cpufreq_governor_internal boolean to
> > indicate when an internal governor, like
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> There are a few places in the code that need to find the slot
> at a given page-table level.
>
> So create a new macro get_table_slot() for that. This will reduce
> the effort to figure out whether the code
On 10.08.2022 21:29, Jason Andryuk wrote:
> Export feature_detect as intel_feature_detect so it can be re-used by
> HWP.
>
> Signed-off-by: Jason Andryuk
> ---
> v2
> export intel_feature_detect with typed pointer
> Move intel_feature_detect to acpi/cpufreq/cpufreq.h since the
> declaration now
On 10.08.2022 21:29, Jason Andryuk wrote:
> acpi-cpufreq scales the aperf/mperf measurements by max_freq, but HWP
> needs to scale by base frequency. Settings max_freq to base_freq
> "works" but the code is not obvious, and returning values to userspace
> is tricky. Add an additonal perf_freq
On 15.08.22 14:47, Juergen Gross wrote:
On 15.08.22 14:34, Jan Beulich wrote:
On 15.08.2022 14:16, Juergen Gross wrote:
On 15.08.22 14:00, Jan Beulich wrote:
On 15.08.2022 13:55, Juergen Gross wrote:
On 15.08.22 13:52, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
---
On 10.08.2022 21:29, Jason Andryuk wrote:
> For hwp, the standard governors are not usable, and only the internal
> one is applicable. Add the cpufreq_governor_internal boolean to
> indicate when an internal governor, like hwp-internal, will be used.
> This is set during presmp_initcall, so that
Hi Julien,
> On 12 Aug 2022, at 20:24, Julien Grall wrote:
>
> From: Julien Grall
>
> Since commit 7e14a47e7c73 ("xen/arm64: head Rework and document
> launch()"), the boot code is setting x22 but not read it.
>
> So remove the two instructions setting x22 and update the documentation
> to
flight 172531 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
On 13.08.2022 03:38, Marek Marczykowski-Górecki wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -669,6 +669,51 @@ bool_t iommu_has_feature(struct domain *d, enum
> iommu_feature feature)
> return is_iommu_enabled(d) && test_bit(feature,
On 13.08.2022 03:38, Marek Marczykowski-Górecki wrote:
> It doesn't modify it, and it will be necessary in a subsequent patch.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
flight 172542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172542/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6
On 13.08.2022 03:38, Marek Marczykowski-Górecki wrote:
> From: Connor Davis
>
> [Connor]
> Xue is a cross-platform USB 3 debugger that drives the Debug
> Capability (DbC) of xHCI-compliant host controllers. This patch
> implements the operations needed for xue to initialize the host
>
On 15.08.22 14:34, Jan Beulich wrote:
On 15.08.2022 14:16, Juergen Gross wrote:
On 15.08.22 14:00, Jan Beulich wrote:
On 15.08.2022 13:55, Juergen Gross wrote:
On 15.08.22 13:52, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++
On 15.08.2022 14:16, Juergen Gross wrote:
> On 15.08.22 14:00, Jan Beulich wrote:
>> On 15.08.2022 13:55, Juergen Gross wrote:
>>> On 15.08.22 13:52, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@
On 15.08.2022 13:04, Juergen Gross wrote:
> Cpu cpu unplugging is calling schedule_cpu_rm() via stop_machine_run()
> with interrupts disabled, thus any memory allocation or freeing must
> be avoided.
>
> Since commit 5047cd1d5dea ("xen/common: Use enhanced
> ASSERT_ALLOC_CONTEXT in xmalloc()")
On 15.08.22 14:00, Jan Beulich wrote:
On 15.08.2022 13:55, Juergen Gross wrote:
On 15.08.22 13:52, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3237,6 +3237,65 @@ out:
return ret;
}
+static struct
flight 172540 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 15.08.2022 13:58, Juergen Gross wrote:
> On 15.08.22 13:41, Jan Beulich wrote:
>> On 15.08.2022 13:04, Juergen Gross wrote:
>>> For updating the node affinities of all domains in a cpupool add a new
>>> function cpupool_update_node_affinity().
>>>
>>> In order to avoid multiple allocations of
On 15.08.2022 13:55, Juergen Gross wrote:
> On 15.08.22 13:52, Jan Beulich wrote:
>> On 15.08.2022 13:04, Juergen Gross wrote:
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -3237,6 +3237,65 @@ out:
>>> return ret;
>>> }
>>>
>>> +static struct cpu_rm_data
On 15.08.22 13:41, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
For updating the node affinities of all domains in a cpupool add a new
function cpupool_update_node_affinity().
In order to avoid multiple allocations of cpumasks carve out memory
allocation and freeing from
On 15.08.22 13:52, Jan Beulich wrote:
On 15.08.2022 13:04, Juergen Gross wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3237,6 +3237,65 @@ out:
return ret;
}
+static struct cpu_rm_data *schedule_cpu_rm_alloc(unsigned int cpu)
+{
+struct cpu_rm_data *data;
On 15.08.2022 13:50, Dylanger Daly wrote:
> Indeed adding noreboot does result in the device just hanging there after
> starting a VM.
>
> I wonder if it's possible to have Xen write out it's log to some memory
> address, hoping it's doing a warm reset the log messages should still be
>
On 15.08.2022 13:04, Juergen Gross wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -3237,6 +3237,65 @@ out:
> return ret;
> }
>
> +static struct cpu_rm_data *schedule_cpu_rm_alloc(unsigned int cpu)
> +{
> +struct cpu_rm_data *data;
> +const struct
Hi Jan,
Indeed adding noreboot does result in the device just hanging there after
starting a VM.
I wonder if it's possible to have Xen write out it's log to some memory
address, hoping it's doing a warm reset the log messages should still be
present.
Cheers
On 15.08.2022 13:04, Juergen Gross wrote:
> For updating the node affinities of all domains in a cpupool add a new
> function cpupool_update_node_affinity().
>
> In order to avoid multiple allocations of cpumasks carve out memory
> allocation and freeing from domain_update_node_affinity() into
On 8/11/22 12:48, Anthony PERARD wrote:
Patch "tools: Add -Werror by default to all tools/" have added
"-Werror" to CFLAGS in tools/Rules.mk, remove it from every other
makefiles as it is now duplicated.
Signed-off-by: Anthony PERARD
Acked-by: Christian Lindig
---
On 8/11/22 12:48, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
Reviewed-by: Henry Wang
---
tools/flask/utils/Makefile | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index db567b13dc..6be134142a
On 15.08.2022 13:07, Dylanger Daly wrote:
> It would appear this issue isn't specific to the Lenovo Yoga Slim 7 ProX,
> someone else in the Qubes community is having the same issue
> (https://github.com/QubesOS/qubes-issues/issues/7620#issuecomment-1209114810)
>
> Can anyone shed some light on
Hi All,
It would appear this issue isn't specific to the Lenovo Yoga Slim 7 ProX,
someone else in the Qubes community is having the same issue
(https://github.com/QubesOS/qubes-issues/issues/7620#issuecomment-1209114810)
Can anyone shed some light on what possibly might be making a Xen 4.14
In order to prepare not allocating or freeing memory from
schedule_cpu_rm(), move this functionality to dedicated functions.
For now call those functions from schedule_cpu_rm().
No change of behavior expected.
Signed-off-by: Juergen Gross
---
V2:
- add const (Jan Beulich)
- use "unsigned int"
A recent change in the hypervisor memory allocation framework led to
crashes when unplugging host cpus.
This was due to the (correct) assertion that allocating and freeing
memory is allowed with enabled interrupts only. As the main cpu unplug
operation is done in stop-machine context, this
For updating the node affinities of all domains in a cpupool add a new
function cpupool_update_node_affinity().
In order to avoid multiple allocations of cpumasks carve out memory
allocation and freeing from domain_update_node_affinity() into new
helpers, which can be used by
Cpu cpu unplugging is calling schedule_cpu_rm() via stop_machine_run()
with interrupts disabled, thus any memory allocation or freeing must
be avoided.
Since commit 5047cd1d5dea ("xen/common: Use enhanced
ASSERT_ALLOC_CONTEXT in xmalloc()") this restriction is being enforced
via an assertion,
flight 172536 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172536/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
build-amd64-libvirt 6
flight 172529 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172529/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-examine 6 xen-install fail in 172502 pass in 172529
test-arm64-arm64-xl-seattle 8
On 15.08.2022 11:33, Andrew Cooper wrote:
> On 15/08/2022 09:26, Jan Beulich wrote:
>> On 05.08.2022 12:38, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/spec_ctrl.c
>>> +++ b/xen/arch/x86/spec_ctrl.c
>>> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
>>> * mappings.
>>>
On 15/08/2022 09:26, Jan Beulich wrote:
> On 05.08.2022 12:38, Andrew Cooper wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
>> * mappings.
>> */
>> if ( opt_rsb_hvm )
>> +{
>>
flight 172537 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 15.08.2022 10:15, Andrew Cooper wrote:
> On 15/08/2022 09:01, Jan Beulich wrote:
>> On 17.05.2022 17:31, Roger Pau Monne wrote:
>>> Roger Pau Monne (3):
>>> amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
>>> amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: Xen 4.17: Current status of series floating in ML
> >>> ** Blocker List **:
> >>> 2. tools/xenstore: add some new features to the documentation
> >>> https://patchwork.kernel.org/project/xen-devel/list/?series=665064
>
On 15/08/2022 09:21, Henry Wang wrote:
-Original Message-
From: Julien Grall
Subject: Re: Xen 4.17: Current status of series floating in ML
On 15/08/2022 06:46, Henry Wang wrote:
Hi all,
Hi Henry,
Thanks for the list!
No problem, always feel good if this can help the community.
On 05.08.2022 12:38, Andrew Cooper wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
> * mappings.
> */
> if ( opt_rsb_hvm )
> +{
>
On 15.08.2022 10:17, Julien Grall wrote:
> On 15/08/2022 07:43, Jan Beulich wrote:
>> On 12.08.2022 21:24, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> At the moment, the strings are in text right after each use because
>>> the instruction 'adr' has specific requirement on the location
>>>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: Xen 4.17: Current status of series floating in ML
> On 15/08/2022 06:46, Henry Wang wrote:
> > Hi all,
>
> Hi Henry,
>
> Thanks for the list!
No problem, always feel good if this can help the community.
> > **
Hi Jan,
On 15/08/2022 07:43, Jan Beulich wrote:
On 12.08.2022 21:24, Julien Grall wrote:
From: Julien Grall
At the moment, the strings are in text right after each use because
the instruction 'adr' has specific requirement on the location
and the compiler will forbid cross section label.
On 15/08/2022 09:01, Jan Beulich wrote:
> On 17.05.2022 17:31, Roger Pau Monne wrote:
>> Roger Pau Monne (3):
>> amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
>> amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests
>> amd/msr: implement VIRT_SPEC_CTRL for HVM
On 15/08/2022 06:46, Henry Wang wrote:
Hi all,
Hi Henry,
Thanks for the list!
** Blocker List **:
1. Patch: x86: enable interrupts around dump_execstate()
https://patchwork.kernel.org/project/xen-devel/patch/e717897f-980d-ad44-31d9-39f5e7e1c...@suse.com/
Status: Waiting for review.
2.
flight 172524 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On 17.05.2022 17:31, Roger Pau Monne wrote:
> Roger Pau Monne (3):
> amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top of SPEC_CTRL
> amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests
> amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD
I came to realize that
Hi Jan,
Thanks for your patience and detailed review of the list.
> -Original Message-
> From: Jan Beulich
> Subject: Re: Xen 4.17: Current status of series floating in ML
>
> On 15.08.2022 07:46, Henry Wang wrote:
> > 11. vpci: first series in preparation for vpci on ARM
> >
On 15.08.2022 07:46, Henry Wang wrote:
> 11. vpci: first series in preparation for vpci on ARM
> https://patchwork.kernel.org/project/xen-devel/list/?series=660828
> Status: Patch #1 needs actions from author. Patch #2 #3 need review.
It's more than just review. I've expressed elsewhere that I'm
flight 172533 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 12.08.2022 19:33, Andrew Cooper wrote:
> * Always emit current. It's critically important.
I agree it may be relevant, yet I'm not convinced of "critically". But
anyway.
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -768,8 +768,14 @@ static int cf_check
On 11.08.2022 18:48, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.toolstack-build-system-v4
>
> Changes in v4:
> - several new patches
> - some changes to other patches listed in their changelogs
I've
On 12.08.2022 21:24, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, the strings are in text right after each use because
> the instruction 'adr' has specific requirement on the location
> and the compiler will forbid cross section label.
>
> The macro 'adr_l' was recently reworked
flight 172527 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
97 matches
Mail list logo
