flight 134084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134084/
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
Extend smbios type 2 struct to match specification, add support to
override strings from toolstack.
Signed-off-by: Xin Li
---
CC: Igor Druzhinin
CC: Sergey Dyasli
CC: Andrew Cooper
---
tools/firmware/hvmloader/smbios.c | 64 -
tools/firmware/hvmloader/smbios_ty
flight 134079 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134079/
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 134056 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134056/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> I have been testing the python3 changes committed to xen and found a few
> issues. There are a couple of ocaml python build scripts that don't work
> for me with python3, and I needed a few fixes to get pygrub to work,
> mostly
flight 134050 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 134077 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134077/
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
Marek,
thanks for pointing this out. I will fix this tomorrow
Lars
> On 21 Mar 2019, at 23:11, Marek Marczykowski-Górecki
> wrote:
>
> Signed PGP part
> Hi,
>
> Looks like the new website doesn't list Xen 4.8.5:
>
> https://xenproject.org/downloads/xen-project-archives/xen-project-4-8-series/
I have been testing the python3 changes committed to xen and found a few
issues. There are a couple of ocaml python build scripts that don't work
for me with python3, and I needed a few fixes to get pygrub to work,
mostly due to the change from strings to bytes. I am attaching the patch I
put t
On Mon, Mar 25, 2019 at 09:32:28PM +0200, Sakari Ailus wrote:
> %pF and %pf are functionally equivalent to %pS and %ps conversion
> specifiers. The former are deprecated, therefore switch the current users
> to use the preferred variant.
>
> The changes have been produced by the following command:
Hi,
When adding altp2m=1 argument to xen,xen-bootargs via DTB, I can see the
parameter passed via xl info:
xen_commandline: console=dtuart dtuart=serial0 dom0_mem=1G
bootscrub=0 maxcpus=1 timer_slop=0* altp2m=1*
However, I got an error like this at booting phase:
(XEN) parameter "*altp2
flight 134075 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 hos
%pF and %pf are functionally equivalent to %pS and %ps conversion
specifiers. The former are deprecated, therefore switch the current users
to use the preferred variant.
The changes have been produced by the following command:
git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' |
On 3/25/19 10:11 AM, Ryan Thibodeaux wrote:
> On Mon, Mar 25, 2019 at 09:43:20AM -0400, Boris Ostrovsky wrote:
>> On 3/25/19 8:05 AM, luca abeni wrote:
>>> Hi all,
>>>
>>> On Sat, 23 Mar 2019 11:41:51 +0100
>>> luca abeni wrote:
>>> [...]
>> Is there any data that shows effects of using this n
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross 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.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Dari
On Mon, 25 Mar 2019 at 15:59, Stefan Hajnoczi wrote:
>
> The following changes since commit d97a39d903fe33c45be83ac6943a2f82a3649a11:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
> into staging (2019-03-22 09:37:38 +)
>
> are available in the Git repository
On Mon, Mar 25, 2019 at 10:11:38AM -0400, Ryan Thibodeaux wrote:
> > > [...]
> > Is there any data that shows effects of using this new parameter?
> >
Continuing with the experimental data conversation (thanks to Luca and
Dario for being so generous), I am providing more results from qu
On 25/03/2019 15:24, Jan Beulich wrote:
On 21.03.19 at 21:26, wrote:
>> It turns out that this code was previously dead.
> If it was entirely dead, why the rush to get the change into 4.12?
> (I suppose the later parts of description are then justifying why
> the code wasn't actually dead, an
On Fri, Mar 22, 2019 at 10:44:33AM +, Oleksandr Andrushchenko wrote:
>
> On 3/20/19 5:50 AM, Munehisa Kamata wrote:
> > On 3/18/2019 3:02 AM, Oleksandr Andrushchenko wrote:
> >> +Amazon
> >> pls see inline
> > Hi Oleksandr,
> >
> > Let me add some comments as the original author of the series.
>>> On 25.03.19 at 12:12, wrote:
> Currently cpu_sig struct is not updated during boot when either:
>
> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
> 2. initrd does not contain a microcode blob
What about "ucode="?
> These will result in cpu_sig.rev being 0 which aff
On 3/25/2019 8:53 AM, Jan Beulich wrote:
On 22.03.19 at 10:53, wrote:
2) Xen Source - here is the log of an attempt adding "cpuinfor maxcpus=1"
as an option in myman_xen.cfg:
https://pastebin.com/ifHZqCuX (6months)
Well, the "maxcpus=1" doesn't really hide the issue (anymore) because
we now b
flight 134068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134068/
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
Most pkgconfig files contain a Libs: variable, which is either /usr/lib
or /usr/lib64. If a 32bit and a 64bit variant of xen libraries is
installed, the last one wins. As a result compiling for the other
bitsize will fail.
Instead of sharedir use libdir as install target. This matches both the
doc
From: Markus Armbruster
Some trace points are attributed to the wrong source file. Happens
when we neglect to update trace-events for code motion, or add events
in the wrong place, or misspell the file name.
Clean up with help of cleanup-trace-events.pl. Same funnies as in the
previous commit,
From: Markus Armbruster
Emit comments with shortened file names (previous commit).
Limit search to the input file's directory.
Cope with properties tcg (commit b2b36c22bd8) and vcpu (commit
3d211d9f4db).
Cope with capital letters in function names.
Signed-off-by: Markus Armbruster
Message-id
From: Markus Armbruster
Almost all trace-events point to docs/devel/tracing.txt in a comment
right at the beginning. Touch up the ones that don't.
[Updated with Markus' new commit description wording.
--Stefan]
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Message-id:
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's
dtrace(1) tool prints a warning when processing this input file.
This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there
If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.
This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug
From: Markus Armbruster
Tracked down with cleanup-trace-events.pl. Funnies requiring manual
post-processing:
* block.c and blockdev.c trace points are in block/trace-events.
* hw/block/nvme.c uses the preprocessor to hide its trace point use
from cleanup-trace-events.pl.
* include/hw/xen/xe
The following changes since commit d97a39d903fe33c45be83ac6943a2f82a3649a11:
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request'
into staging (2019-03-22 09:37:38 +)
are available in the Git repository at:
git://github.com/stefanha/qemu.git tags/tracing-pull-reque
>>> On 22.03.19 at 10:53, wrote:
> 2) Xen Source - here is the log of an attempt adding "cpuinfor maxcpus=1"
> as an option in myman_xen.cfg:
> https://pastebin.com/ifHZqCuX (6months)
Well, the "maxcpus=1" doesn't really hide the issue (anymore) because
we now bring up all secondary processors de
>>> On 21.03.19 at 21:26, wrote:
> It turns out that this code was previously dead.
If it was entirely dead, why the rush to get the change into 4.12?
(I suppose the later parts of description are then justifying why
the code wasn't actually dead, and why it was getting in the way,
but I think th
On Mon, Mar 25, 2019 at 05:13:00PM +0200, Sakari Ailus wrote:
> All other invalid pointer conversion specifiers currently result into a
> warning only. I see that as an orthogonal change to this set. I found
> another issue in checkpatch.pl that may require some discussion; would you
> be ok with
Hi Andy,
On Sun, Mar 24, 2019 at 11:19:32PM +0200, Andy Shevchenko wrote:
> On Sun, Mar 24, 2019 at 11:10:08PM +0200, Sakari Ailus wrote:
> > On Fri, Mar 22, 2019 at 07:05:50PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 22, 2019 at 03:53:50PM +0200, Sakari Ailus wrote:
> > >
> > > > Porting
On 25/03/2019 11:33, Wei Liu wrote:
> On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
>> On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
>>> CentOS 6 is probably the most frequently broken build, so adding it to CI
>>> would be a very good move.
>>>
>>> One problem is that C
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jennifer Herbert
> Sent: 25 March 2019 14:24
> To: Boris Ostrovsky ; x...@kernel.org;
> xen-devel@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross ; Stefano Stabel
Hi,
On Mon, 25 Mar 2019 09:43:20 -0400
Boris Ostrovsky wrote:
[...]
> > http://retis.santannapisa.it/luca/XenTimers/
> > (there also is a link to the scripts to be used for reproducing the
> > results). The latencies have been measured by running cyclictest in
> > the guest (see the scripts for d
On 24/03/2019 03:50, Roger Pau Monné wrote:
> On Fri, Mar 22, 2019 at 10:06:45AM +0100, Laszlo Ersek wrote:
>> The core PciBusDxe driver that is built into OVMF certainly does the
>> resource allocation/placement, but when OVMF is executed on Xen, this
>> functionality of PciBusDxe is dynamically d
On 21/03/19 17:49, Jennifer Herbert wrote:
On 19/03/19 23:06, Boris Ostrovsky wrote:
On 3/19/19 4:02 PM, Jennifer Herbert wrote:
The ACPI tables doesn't always contain all IRQs for legacy devices
such as RTC. Since no PIC controller is visible for a PV linux guest,
under Xen, legacy_pic cu
flight 134041 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134041/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, Mar 25, 2019 at 09:43:20AM -0400, Boris Ostrovsky wrote:
> On 3/25/19 8:05 AM, luca abeni wrote:
> > Hi all,
> >
> > On Sat, 23 Mar 2019 11:41:51 +0100
> > luca abeni wrote:
> > [...]
> Is there any data that shows effects of using this new parameter?
>
> >>> Yes, I've done
On 3/25/19 8:05 AM, luca abeni wrote:
> Hi all,
>
> On Sat, 23 Mar 2019 11:41:51 +0100
> luca abeni wrote:
> [...]
Is there any data that shows effects of using this new parameter?
>>> Yes, I've done some research and experiments on this. I did it
>>> together with a friend, which I
Hi all,
Xen 4.12 rc7 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc7
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc7/xen-4.12.0-rc7.tar.gz
And the signature is at:
https://downloads.xenproject.org/
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 processor(Dhyana) originates from AMD
technology
Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.
Signed-off-by: Pu Wen
Acked-by: Wei Liu
---
tools/libxc/xc_cpuid_x86.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x
As Hygon Dhyana CPU share similar PMU architecture with AMD family
17h one, so add Hygon Dhyana support in vpmu_arch_initialise() and
vpmu_init() by sharing AMD code path.
Split the common part in amd_vpmu_init() to a static function
_vpmu_init(), making AMD and Hygon to call the shared function t
>>> On 25.03.19 at 10:09, wrote:
>> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
>> Sent: 22 March 2019 12:09
>>
>> In the case of any errors, finish_type_change() passes values returned
>> from p2m->recalc() up the stack (with some exceptions in the case where
>> an error is ex
The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/include/asm-x86/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/as
Add Hygon Dhyana support to handle HyperTransport range.
Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/dom0_build.c | 3 ++-
xen/arch/x86/domai
Add Hygon Dhyana support to use modern APIC.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/apic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 2a24326..004d685 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@
The Hygon Dhyana family 18h processor shares the same cpuid leaves as
the AMD family 17h one. So add Hygon Dhyana support to caculate the
cpuid policies as the AMD CPU does.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpuid.c | 10 +++---
1 file changed, 7 insertions(+), 3
The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR_01DD. So add support for it if the boot param
ler is true.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/traps.c
Add Hygon Dhyana support to update cpuid info for creating PV guest.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/domctl.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bf2d08..19b7bdd 1006
The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.
Signed-off-by: Pu
The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/spec_ctrl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arc
The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/mtrr/g
The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/cpu/common.c | 3 ++-
xen/arch/x86/cpu/mcheck/amd_no
Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.
Signed-off-by: Pu Wen
Acked-by: Jan Beulich
---
xen/arch/x86/acpi/cpu_idle.c | 3 ++-
xen/arch/x86/acpi/cpufreq/cpufreq.c | 8 +---
xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
3 fil
flight 134043 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134043/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 210bd16aff81f6746033dfc0c4cc7c463349bce0
baseline version:
ovmf f4c5200926df8aa8e4ede
Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.
To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
for sy
>>> On 20.03.19 at 19:27, wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/pci/proc.c: In function ‘proc_bus_pci_ioctl’:
> drivers/pci/proc.c:216:6: warning: this state
On 25/03/2019 13:21, Dario Faggioli wrote:
> On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
>> --- a/xen/include/xen/cpu.h
>> +++ b/xen/include/xen/cpu.h
>> @@ -32,23 +32,25 @@ void register_cpu_notifier(struct notifier_block
>> *nb);
>> * (a) A CPU is going down; or (b) CPU_UP_CANCELED
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> --- a/xen/include/xen/cpu.h
> +++ b/xen/include/xen/cpu.h
> @@ -32,23 +32,25 @@ void register_cpu_notifier(struct notifier_block
> *nb);
> * (a) A CPU is going down; or (b) CPU_UP_CANCELED
> */
> /* CPU_UP_PREPARE: Preparing to bring C
Hi all,
On Sat, 23 Mar 2019 11:41:51 +0100
luca abeni wrote:
[...]
> > > Is there any data that shows effects of using this new parameter?
> > >
> > Yes, I've done some research and experiments on this. I did it
> > together with a friend, which I'm Cc-ing, as I'm not sure we're
> > ready/ca
flight 134035 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134035/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-libvirt
On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross 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.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Da
On Sat, 2019-03-16 at 14:14 +0100, Juergen Gross wrote:
> On 16/03/2019 04:01, Dario Faggioli wrote:
> > > So we can just omit the call of cpu_disable_scheduler() when
> > > offlining
> > > a cpu due to suspend and on resuming we can omit taking the
> > > schedule
> > > lock for selecting the new
On 25/03/2019 11:53, Dario Faggioli wrote:
> On Sat, 2019-03-23 at 14:22 +0100, Juergen Gross wrote:
>> On 23/03/2019 03:32, Dario Faggioli wrote:
>>> To properly deal with offline CPUs, I think we can change the logic
>>> a
>>> little, i.e., we initialize the smt_idle mask to all-1 (all CPUs
>>> i
On Mon, Mar 25, 2019 at 11:12:17AM +, Sergey Dyasli wrote:
>Currently cpu_sig struct is not updated during boot when either:
>
>1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>2. initrd does not contain a microcode blob
>
>These will result in cpu_sig.rev being 0 which
On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
> On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
> > CentOS 6 is probably the most frequently broken build, so adding it to CI
> > would be a very good move.
> >
> > One problem is that CentOS 6 comes with Python 2.6, and Qem
On Fri, Mar 22, 2019 at 11:12:28AM +, Andrew Cooper wrote:
> The script is mostly indented with spaces, but there are three tabs. Fix them
> up to be consistent.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
X
On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
> CentOS 6 is probably the most frequently broken build, so adding it to CI
> would be a very good move.
>
> One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
> There appear to be no sensible ways to get Python
Currently cpu_sig struct is not updated during boot when either:
1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
2. initrd does not contain a microcode blob
These will result in cpu_sig.rev being 0 which affects APIC's
check_deadline_errata() and retpoline_safe() functions
On Sat, 2019-03-23 at 14:22 +0100, Juergen Gross wrote:
> On 23/03/2019 03:32, Dario Faggioli wrote:
> > To properly deal with offline CPUs, I think we can change the logic
> > a
> > little, i.e., we initialize the smt_idle mask to all-1 (all CPUs
> > idle),
> > and we also make sure that we set th
On Sun, 2019-03-24 at 14:07 -0400, Boris Ostrovsky wrote:
> On Sat, Mar 23, 2019 at 08:00:52AM -0400, Ryan Thibodeaux wrote:
> > This test system was configured to use a TSC clocksource, disabled
> > C states, and lowered the timer slop. I am not claiming the timer
> > slop change was solely respon
On Mon, Mar 25, 2019 at 10:30 AM Rafael J. Wysocki wrote:
>
> On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
> wrote:
> >
> > %pS and %ps are now the preferred conversion specifiers to print function
> > %names. The functionality is equivalent; remove the old, deprecated %pF
> > %and %pf support.
>
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_misc.c | 20 ++
> tools/misc/Makefile | 4 ++
On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
wrote:
>
> %pF and %pf are functionally equivalent to %pS and %ps conversion
> specifiers. The former are deprecated, therefore switch the current users
> to use the preferred variant.
>
> The changes have been produced by the following command:
>
>
On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
wrote:
>
> %pS and %ps are now the preferred conversion specifiers to print function
> %names. The functionality is equivalent; remove the old, deprecated %pF
> %and %pf support.
Are %pF and %pf really not used any more in the kernel?
If that is not t
> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 22 March 2019 12:09
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; Wei Liu ; Roger Pau Monne
> ;
> George Dunlap ; Alexandru Stefan ISAILA
>
> Sub
>>> On 22.03.19 at 20:56, wrote:
> On 19/03/2019 09:16, Jan Beulich wrote:
>> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
>> families") converted certain checks for Fam11 to include families all
>> the way up to Fam17. The commit having no description, it is hard to
>> te
>>> On 22.03.19 at 21:19, wrote:
> On 18/03/2019 14:58, Jan Beulich wrote:
> On 18.03.19 at 15:11, wrote:
>>> On 18/03/2019 13:20, Jan Beulich wrote:
>>> On 18.03.19 at 12:27, wrote:
> * Some of the single-byte versions specify "=q" as the output. This is a
>remnent of the
82 matches
Mail list logo
