flight 134272 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134272/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 134254 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134254/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c27ec42363515bda97468dccf57a01c6e66d01e
baseline version:
ovmf 8028f03032182f2c72e76
flight 134251 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On Mon, Mar 25, 2019 at 09:38:21AM +, Sergey Dyasli wrote:
>On 11/03/2019 07:57, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
>> tools/libxc/include/xenctrl.h | 1 +
>> tools/libxc/xc_m
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, March 28, 2019 3:53 AM
>
> This has been problematic since its introduction in Xen 4.3
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-dev
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:49 PM
>
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:52 PM
>
> Introduce a respective element in struct iommu_init_ops.
>
> Take the liberty and also switch intel_iommu_supports_eim() to bool/
> true/false, to fully match the hook's type.
>
> Signed-off-by: Jan Beul
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 29, 2019 5:13 PM
>
> >>> On 28.03.19 at 18:37, wrote:
> > On 28/03/2019 14:53, Jan Beulich wrote:
> >> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> >> keyhandler_fn_t vtd_dump_iommu_info;
> >>
> >> bool intel_i
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 28, 2019 10:55 PM
>
> Move this into iommu_hardware_setup() and make that function non-
> inline. Move its declaration into common code.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
__
This run is configured for baseline tests only.
flight 83856 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83856/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
Hi all,
based on the doodle poll, we are changing the community call day to the first
Thursday of each month.
Please propose topics by either editing the running agenda document at
https://docs.google.com/document/d/1B279exjoLW1-7aL4Y-dxtS8NY-EUwJ7uTt8qEKWAmFY/edit#heading
or by replying to th
flight 134255 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Add a new cpu notifier action CPU_RESUME_FAILED which is called for all
cpus which failed to come up at resume. The calls will be done after
all other cpus are already up in order to know which resources are
available then.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
Reviewed-by: Ge
Instead of removing cpus temporarily from cpupools during
suspend/resume only remove cpus finally which didn't come up when
resuming.
Signed-off-by: Juergen Gross
Reviewed-by: George Dunlap
Reviewed-by: Dario Faggioli
---
V2:
- add comment (George Dunlap)
---
xen/common/cpupool.c | 131 +
Today there is special handling in cpu_disable_scheduler() for suspend
by forcing all vcpus to the boot cpu. In fact there is no need for that
as during resume the vcpus are put on the correct cpus again.
So we can just omit the call of cpu_disable_scheduler() when offlining
a cpu due to suspend a
Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.
It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume.
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just need to hold the domain RCU
lock and need the sche
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This can be simplified a lot by not performing a complete cpu down and
up cycle for the non-boot cpus, but keeping the pure software related
state and freeing it only
Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
for a cpu with a specified action, returning an errno value.
This avoids coding the same pattern multiple times.
While at it avoid side effects from using BUG_ON() by not using
cpu_online(cpu) as a parameter.
Signed-off-by: Jue
On 4/1/19 9:35 AM, Juergen Gross wrote:
On 22/03/2019 08:37, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In
flight 134258 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134258/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 06b019117682c0d91074b4368e37acdd48f026f4
baseline version:
freebsd 8b558001903
This is a note to let you know that I've just added the patch titled
x86/asm: Rewrite sync_core() to use IRET-to-self
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-asm
This is a note to let you know that I've just added the patch titled
x86/asm: Rewrite sync_core() to use IRET-to-self
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-asm
On 2019/4/1 16:36, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
@@ -876,6 +877,10 @@ static int __init vpmu_init(void)
if ( amd_vpmu_init() )
vpmu_mode = XENPMU_MODE_OFF;
break;
+case X86_VENDOR_HYGON:
+if ( hygon_vpmu_init() )
+ vpmu_mo
On 2019/4/1 16:41, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
I think it would have been nice if you had mentioned the real
reason why y
101 - 126 of 126 matches
Mail list logo
