struct privcmd_buf_vma_private has a zero-sized array at the end
(pages), use the new struct_size() helper to determine the proper
allocation size and avoid potential type mistakes.
Signed-off-by: Andrea Righi
---
drivers/xen/privcmd-buf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
flight 134264 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134264/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134315 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134315/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 8:57 PM
>
> In x2APIC mode it is 32 bits wide. Not having returned the full value
> was mostly benign: We never modify the ID based on its original value;
> full new values get written at all times. It was "just" debug
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 9:17 PM
>
> >>> On 02.04.19 at 05:24, wrote:
> >> 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
flight 134309 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134309/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
flight 134307 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134307/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On 21/03/2019 10:25, Amit Singh Tomar wrote:
> The meson-uart.c is an ARM specific UART driver for the Amlogic MESON
> SoC family.
>
> Signed-off-by: Amit Singh Tomar
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 21/03/2019 10:25, Amit Singh Tomar wrote:
> This patch adds driver for UART controller present on Amlogic Meson
> SoCs and it has been tested on Nanopi K2 board based on S905 SoC.
>
> Controller registers defination is taken from Linux 4.20.
>
On 21/03/2019 10:25, Amit Singh Tomar wrote:
> Signed-off-by: Amit Singh Tomar
Apart from the missing commit message:
Reviewed-by: Andre Przywara
Tested-by: Andre Przywara
Cheers,
Andre.
> ---
> TODO:
> * Capture XEN boot info on WIKI.
>
> Changes since v1:
>
> * Fixed
This is some work which was discussed for L1TF and never got finished.
Testing for this work is what discovered the cpu online/offline memory leak.
Andrew Cooper (3):
xen/cpu: Distinguish "cpu already in that state" in cpu_{up,down}()
x86/sysctl: Clean up XEN_SYSCTL_cpu_hotplug
x86: Support
Currently, a user can in combine the output of `xl info -n`, the APCI tables,
and some manual CPUID data to figure out which CPU numbers to feed into
`xen-hptool cpu-offline` to effectively disable SMT at runtime.
A more convenient option is to teach Xen how to perform this action.
First of all,
A future change is going to introduce two more cases. Instead of opcoding the
XSM checks and contine_hypercall logic, collect the data into local variables.
Switch the default return value to -EOPNOTSUPP to distinguish a bad op from a
bad cpu index.
Signed-off-by: Andrew Cooper
---
CC: Jan
All methods of querying the online state of a CPU are racy without the hotplug
lock held, which can lead to a TOCTOU race trying to online or offline CPUs.
Distinguish this case with -EEXIST rather than -EINVAL, so the caller can take
other actions if necessary.
While adjusting this, rework the
flight 134224 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134287 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134287/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On 02/04/2019 17:42, Julien Grall wrote:
> diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
> index 97466a12b1..35a47c7229 100644
> --- a/xen/arch/arm/early_printk.c
> +++ b/xen/arch/arm/early_printk.c
> @@ -17,9 +17,10 @@
> void early_putch(char c);
> void
On 02/04/2019 17:14, Pu Wen wrote:
> On 2019/4/2 23:46, Jan Beulich wrote:
>> On 02.04.19 at 13:58, wrote:
>>> On 2019/4/2 18:20, Jan Beulich wrote:
On 02.04.19 at 08:46, wrote:
> On 2019/4/1 16:41, Jan Beulich wrote:
>> On 30.03.19 at 11:42, wrote:
>>> There is no
This is actually v2 of the patch posted in [1]. Please see the thread
starting there for more context...
The semantics of sector based quanties, such as first_sect and last_sect in
blkif_request_segment, and the value of "sectors" in the backend info
in xenstore have become confused. Some
2 paths in the domU console handling are now the same. So they can be
merged to make the code simpler.
Signed-off-by: Julien Grall
---
xen/drivers/char/console.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
Hi all,
This series contains a bunch of bug fixes for the hypercall CONSOLEIO_write
and some documentation.
Note the patch #2 was originally sent in standalone, I have included here
with comments addressed to keep everything together.
Cheers,
Julien Grall (4):
xen/console: Properly buffer
After upgrading Debian to Buster, I have began to notice console
mangling when using zsh in Dom0. This is happenning because output sent by
zsh to the console may contain NULs in the middle of the buffer.
The actual implementation of CONSOLEIO_write considers that a buffer
always terminate with a
Currently, OS developpers will have to look at Xen code in order to know
the parameters of an hypercall and how it is meant to work.
This is not a trivial task as you may need to have a deep understanding
of Xen internal.
This patch attempts to document the behavior of HYPERCALL_console_io() to
The output will be buffered if the buffer provided by the DomU does not
contain a newline. This can also happen if buffer provided by DomU is
split in multiple part (Xen can only process 127 characters at the time).
As Xen will remove any non-printable characters, the output buffer may
be smaller
On 2019/4/2 23:50, Jan Beulich wrote:
On 02.04.19 at 14:11, wrote:
>> By the way, how about the patch 01/15 of this series?
>> If it's fine, could you please offer Acked-by tag for it?
>
> I've yet to look at v4 of it.
Andrew said the change of patch 01/15 should rebase over
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:
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
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:
On 2019/4/2 23:46, Jan Beulich wrote:
On 02.04.19 at 13:58, wrote:
On 2019/4/2 18:20, Jan Beulich wrote:
On 02.04.19 at 08:46, wrote:
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
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
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
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
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
>>> On 02.04.19 at 18:00, wrote:
> On 2019/4/2 23:14, Andrew Cooper wrote:
>> On 30/03/2019 10:40, Pu Wen wrote:
>>> This patch series have been applied and tested successfully on Hygon
>>> Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
>>> It works fine and makes no harm
On 02/04/2019 16:46, Jan Beulich wrote:
On 02.04.19 at 13:58, wrote:
>> On 2019/4/2 18:20, Jan Beulich wrote:
>>> On 02.04.19 at 08:46, wrote:
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
>>> On 02.04.19 at 12:26, wrote:
> On 05/03/2019 13:28, Jan Beulich wrote:
>> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
>> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
>> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
On 02/04/2019 06:34, Juergen Gross wrote:
> 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
On 2019/4/2 23:14, Andrew Cooper wrote:
On 30/03/2019 10:40, Pu Wen wrote:
This patch series have been applied and tested successfully on Hygon
Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
It works fine and makes no harm to the existing code.
Reference:
[1]
Dear community members,
I'm pleased to announce that Xen 4.12.0 is released.
Please find the tarball and its signature at:
https://xenproject.org/downloads/xen-project-archives/xen-project-4-12-series/xen-project-4-12-0/
You can also check out the tag in xen.git:
>>> On 02.04.19 at 14:11, wrote:
> By the way, how about the patch 01/15 of this series?
> If it's fine, could you please offer Acked-by tag for it?
I've yet to look at v4 of it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 02.04.19 at 13:58, wrote:
> On 2019/4/2 18:20, Jan Beulich wrote:
>> On 02.04.19 at 08:46, wrote:
>>> 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
>>> On 02.04.19 at 12:30, wrote:
> On 01/04/2019 09:40, 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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
On 30/03/2019 10:40, Pu Wen wrote:
> As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
> is a joint venture between AMD and Haiguang Information Technology Co.,
> Ltd., aims at providing high performance x86 processors for China
> server market.
>
> The first generation Hygon
On 10/01/2019 15:46, Paul Durrant wrote:
>> -Original Message-
>> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
>> Sent: 10 January 2019 15:31
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Razvan Cojocaru ; Konrad
>>
flight 83859 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/83859/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On Tue, Apr 02, 2019 at 06:55:44AM -0600, Jan Beulich wrote:
> Drop redundant ones from apic.h. Add delivery mode mask. Use them in
> place of open coded hex numbers.
>
> Take the opportunity and modify a helper function's parameters to be
> just unsigned int. Also drop the bogus double
>>> On 02.04.19 at 05:24, wrote:
>> 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
On 2019/4/2 20:16, Andrew Cooper wrote:
> On 30/03/2019 10:42, Pu Wen wrote:
>> +static const struct cpu_dev hygon_cpu_dev = {
>> +.c_vendor = "Hygon",
>> +.c_ident= { "HygonGenuine" },
>> +.c_early_init = early_init_amd,
>> +.c_init = init_hygon,
>> +};
>>
In x2APIC mode it is 32 bits wide.
In __print_IO_APIC() drop logging of both physical and logical IDs:
The latter covers a superset of the bits of the former in the RTE, and
we write full 8-bit values anyway even in physical mode for all ordinary
interrupts, regardless of INT_DEST_MODE (see the
On 02/04/2019 13:56, Jan Beulich wrote:
> In x2APIC mode it is 32 bits wide. Not having returned the full value
> was mostly benign: We never modify the ID based on its original value;
> full new values get written at all times. It was "just" debug logging
> which ended up wrong this way (and
This is to accompany sanitize_input(). Just like for initial state we
want to have state between two emulated insns sane, at least as far as
assumptions in the main emulator go. Do minimal checking after segment
register, CR, and MSR writes, and roll back to the old value in case of
failure
On 02/04/2019 13:55, Jan Beulich wrote:
> Drop redundant ones from apic.h. Add delivery mode mask. Use them in
> place of open coded hex numbers.
>
> Take the opportunity and modify a helper function's parameters to be
> just unsigned int. Also drop the bogus double underscore from its name,
> as
In x2APIC mode it is 32 bits wide. Not having returned the full value
was mostly benign: We never modify the ID based on its original value;
full new values get written at all times. It was "just" debug logging
which ended up wrong this way (and which will need adjustment itself as
well, to also
Drop redundant ones from apic.h. Add delivery mode mask. Use them in
place of open coded hex numbers.
Take the opportunity and modify a helper function's parameters to be
just unsigned int. Also drop the bogus double underscore from its name,
as it and all its callers get touched anyway.
No
On 02/04/2019 13:57, Jan Beulich wrote:
On 02.04.19 at 07:34, wrote:
>> 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
On 30/03/2019 10:42, Pu Wen wrote:
> +static const struct cpu_dev hygon_cpu_dev = {
> + .c_vendor = "Hygon",
> + .c_ident= { "HygonGenuine" },
> + .c_early_init = early_init_amd,
> + .c_init = init_hygon,
> +};
> +
> +int __init hygon_init_cpu(void)
> +{
> +
On 2019/4/2 18:21, Jan Beulich wrote:
> On 02.04.19 at 08:46, wrote:
>> On 2019/4/1 16:36, Jan Beulich wrote:
>>> On 30.03.19 at 11:42, wrote:
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
On 2019/4/2 18:20, Jan Beulich wrote:
On 02.04.19 at 08:46, wrote:
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
>>> On 02.04.19 at 07:34, wrote:
> 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
>>> On 02.04.19 at 07:34, wrote:
> 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
>
>>> On 02.04.19 at 07:34, wrote:
> 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
flight 134262 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134262/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
>>> On 01.04.19 at 17:35, wrote:
> On 01/04/2019 15:55, Jan Beulich wrote:
>>
>>> Secondly, when a guest executes CPUID, this doesn't
>>> typically result in Xen executing a CPUID instruction in practice.
>> Wait - this is true for DomU, but used to be false for (PV) Dom0,
>> until you've
>>> On 01.04.19 at 18:59, wrote:
> On 01/04/2019 09:27, Jan Beulich wrote:
> On 29.03.19 at 17:57, wrote:
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -631,6 +631,10 @@ static int cpu_callback(
>>> case CPU_UP_CANCELED:
>>> case CPU_DEAD:
>>>
flight 134216 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 01/04/2019 09:40, 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
>
Hi Jan,
Sorry I was meant to answer to this earlier on.
On 05/03/2019 13:28, Jan Beulich wrote:
The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
originally introduced it (d818f3cb7c ["hvm: Use main
>>> On 02.04.19 at 08:46, wrote:
> On 2019/4/1 16:36, Jan Beulich wrote:
>> On 30.03.19 at 11:42, wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>>> return 0;
>>> }
>>>
>>> -int
>>> On 02.04.19 at 08:46, wrote:
> 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
On 02/04/2019 04:24, Tian, Kevin wrote:
>> 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
On 29/03/2019 09:15, Jan Beulich wrote:
On 28.03.19 at 18:50, wrote:
>> On 28/03/2019 14:54, Jan Beulich wrote:
>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>> @@ -26,6 +26,19 @@
>>> const struct iommu_init_ops *__initdata iommu_init_ops;
>>>
Hi,
You don't have a cover letter, so I will comment here. I will leave Andre
reviewing the patch series.
In the future, please include a cover letter if you send more than one patch
together.
On 21/03/2019 10:25, Amit Singh Tomar wrote:
As I pointed out on v2, you are missing the commit
Hi,
On 02/04/2019 06:34, Juergen Gross wrote:
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
flight 134259 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134259/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134278 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134278/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On Mon, Apr 01, 2019 at 08:36:44PM +, YOUNG, MICHAEL A. wrote:
> On Mon, 1 Apr 2019, Wei Liu wrote:
>
> > Wei Liu (4):
> > pygrub: fix message in grub parser
> > pygrub/grub: always use integer for default entry
> > pygrub: decode string in Python 3
> > tools/ocaml: make python scripts 2
On 01/04/2019 11:47, Juergen Gross wrote:
> On 01/04/2019 10:50, Andrew Cooper wrote:
>> On 29/03/2019 15:09, Juergen Gross wrote:
>>> Make sure the number of vcpus is always a multiple of the scheduling
>>> granularity. Note that we don't support a scheduling granularity above
>>> one on ARM.
>>
On 28/03/2019 00:44, David Howells wrote:
> Convert the xenfs filesystem to the new internal mount API as the old
> one will be obsoleted and removed. This allows greater flexibility in
> communication of mount parameters between userspace, the VFS and the
> filesystem.
>
> See
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() )
+
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
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:
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:
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
84 matches
Mail list logo
