On 08/03/2019 19:37, Igor Druzhinin wrote:
> On 08/03/2019 16:14, Jan Beulich wrote:
> On 08.03.19 at 16:18, wrote:
>>> On 08/03/2019 14:58, Jan Beulich wrote:
>>> On 08.03.19 at 15:25, wrote:
> On 08/03/2019 11:55, Jan Beulich wrote:
>
> I like the latter suggestion more. See
Updating microcode is less error prone when caches have been flushed and
depending on what exactly the microcode is updating. For example, some
of the issues around certain Broadwell parts can be addressed by doing a
full cache flush.
[linux commit: 91df9fdf51492aec9fed6b4cbd33160886740f47]
Signed
During late microcode update, apply_microcode() is invoked in
cpu_request_microcode(). To make late microcode update more reliable,
we want to put the apply_microcode() into stop_machine context. So
we split out it from cpu_request_microcode(). As a consequence,
apply_microcode() should be invoked
to replace the current per-cpu cache 'uci->mc'.
Compared to the current per-cpu cache, the benefits of the global
microcode cache are:
1. It reduces the work that need to be done on each CPU. Parsing ucode
file is done once on one CPU. Other CPUs needn't parse ucode file.
Instead, they can find ou
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
---
xen/arch/x86/a
to a more generic function. Then, this function can compare two given
microcodes' signature/revision as well. Comparing two microcodes is
used to update the global microcode cache (introduced by the later
patches in this series) when a new microcode is given.
Note that enum microcode_match_result
Intel CPU only allows mixing in stepping or 'pf'. If an ucode patch is
for other CPU families or models, it won't be compatible to all CPUs on
current system and even hot-plugged CPUs. Don't save such patch to
reduce the size of ucode cache.
Signed-off-by: Chao Gao
---
v6:
- new
---
xen/arch/x
Struct microcode_info is useless now. microcode pointer and size inside
it were passed to other CPUs to parse microcode locally. Now, parsing
microcode blob is done on one of CPUs. Other CPUs needn't parse the
microcode blob; the pointer and size can be removed.
The 'cpu' field is also redundent b
We can remove the per-cpu cache field in struct ucode_cpu_info since
it has been replaced by a global cache. It would leads to only one field
remaining in ucode_cpu_info. Then, this struct is removed and the
remaining field (cpu signature) is stored in per-cpu area.
Also remove 'microcode_resume_m
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all cores
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 ++
tools/misc/xenmicrocode.c | 89 +
microcode_update_lock and microcode_mutex prevent cores from updating
microcode in parallel. Below changes are made to support parallel
microcode update on cores.
microcode_update_lock is removed. This lock was to prevent logic threads
of a same core from updating microcode at the same time. But d
Major changes in version 6:
- run wbinvd before updating microcode (patch 10)
- add an userspace tool for late microcode update (patch 1)
- scale time to wait by the number of remaining CPUs to respond
- remove 'cpu' parameters from some related callbacks and functins
- save an ucode patch on
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode_intel.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 9657575..22fdeca 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/mic
Hi David,
On 11/22/18 at 11:06am, David Hildenbrand wrote:
> Right now, pages inflated as part of a balloon driver will be dumped
> by dump tools like makedumpfile. While XEN is able to check in the
> crash kernel whether a certain pfn is actuall backed by memory in the
> hypervisor (see xen_oldmem
>>> On 08.03.19 at 19:37, wrote:
> On 08/03/2019 16:14, Jan Beulich wrote:
>> One caveat though: What do you suggest to do with page straddling
>> accesses? The commit introducing these functions was, after all to
>> deal with this special case. The in-flight request we observe there
>> could be f
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.1a-rc1-tag
xen: fixes and features for 5.1-rc1
It contains the following patches:
- a remove of fallback code for very old Xen hypervisors
- 3 patches for fixing Xen dom0 boot regr
On 11.03.19 10:04, Dave Young wrote:
> Hi David,
> On 11/22/18 at 11:06am, David Hildenbrand wrote:
>> Right now, pages inflated as part of a balloon driver will be dumped
>> by dump tools like makedumpfile. While XEN is able to check in the
>> crash kernel whether a certain pfn is actuall backed b
Commit 35a61c05ea ("x86emul: adjust handling of AVX2 gathers") builds
upon the fact that the domain will actually survive running out of MMIO
result buffer space. Drop the domain_crash() invocation. Also delay
incrementing of the usage counter, such that the function can't possibly
use/return an ou
>>> On 08.03.19 at 20:29, wrote:
> Am Fri, 8 Mar 2019 20:20:59 +0100
> schrieb Olaf Hering :
>
>> To reiterate the second paragraph: if a domU uses TSC as primary clock
>> source, it is expected that it runs NTP to cover for the resulting
>> drift. Therefore this change does no need a knob to tu
> > The patch has been merged, would you mind to send a documentation patch
> > for the vmcoreinfo, which is added recently in
> > Documentation/kdump/vmcoreinfo.txt
> >
> > A brief description about how this vmcoreinfo field is used is good to
> > have.
> >
>
> Turns out, it was already docume
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 March 2019 09:56
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH] x86/HVM: don't crash guest in hvmemul_find_mmio_cache()
>
> Commit 35a61c05ea ("x86emul:
flight 133680 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 130965
Tests
>>> On 08.03.19 at 20:20, wrote:
> To reiterate the second paragraph: if a domU uses TSC as primary clock
> source, it is expected that it runs NTP to cover for the resulting
> drift. Therefore this change does no need a knob to turn it on or off.
Did you omit a 't' or a 'w' above? Judging from t
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 March 2019 09:35
> To: Igor Druzhinin
> Cc: Andrew Cooper ; Paul Durrant
> ; xen-devel de...@lists.xenproject.org>; Juergen Gross
> Subject: Re: XenGT is still regressed on master
>
> >>> On 08.03.19 at 19:3
Am Mon, 11 Mar 2019 04:02:14 -0600
schrieb "Jan Beulich" :
> > One interesting aspect is: the xenlinux based kernels report
> > clocksource=tsc,
> I don't think they do - iirc they are hardcoded to clocksource=xen.
For HVM they do:
# dmesg | grep -Ei '(clock|hz)'
[0.00] hpet clockeve
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 08 March 2019 21:31
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; Wei Liu ; Roger Pau Monne
> ;
> Igor Druzhinin
> Subject: [PATCH] x86/hvm: finish IOREQ
>>> On 10.03.19 at 12:38, wrote:
> flight 133666 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/133666/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-libvirt-pair 22 guest-migrat
The presence of this filelock does not allow building several VMs at the same
time. This filelock was added to prevent other xl instances from using memory
freeed for the currently building VM in autoballoon mode.
Signed-off-by: Dmitry Isaykin
---
tools/xl/xl_vmcontrol.c | 14 +-
1 f
>>> On 11.03.19 at 11:21, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 11 March 2019 09:35
>>
>> >>> On 08.03.19 at 19:37, wrote:
>> > On 08/03/2019 16:14, Jan Beulich wrote:
>> >> One caveat though: What do you suggest to do with page straddling
>> >> accesses? The commit int
>>> On 11.03.19 at 11:26, wrote:
> Am Mon, 11 Mar 2019 04:02:14 -0600
> schrieb "Jan Beulich" :
>
>> > One interesting aspect is: the xenlinux based kernels report
> clocksource=tsc,
>> I don't think they do - iirc they are hardcoded to clocksource=xen.
>
> For HVM they do:
There's no such t
>>> On 11.03.19 at 11:11, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 11 March 2019 09:56
>> To: xen-devel
>> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
>> ; Wei Liu
>> Subject: [PATCH] x86/HVM: don't crash guest in hvmemul_find_mmio_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 March 2019 10:45
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu
> ; xen-devel
> Subject: RE: [PATCH] x86/HVM: don't crash guest in hvmemul_find_mmio_cache()
>
> >>> On 11.03.19 at 11:11,
Am Mon, 11 Mar 2019 04:16:07 -0600
schrieb "Jan Beulich" :
> >>> On 08.03.19 at 20:20, wrote:
> > To reiterate the second paragraph: if a domU uses TSC as primary clock
> > source, it is expected that it runs NTP to cover for the resulting
> > drift. Therefore this change does no need a knob to
>>> On 11.03.19 at 11:30, wrote:
>> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
>> Sent: 08 March 2019 21:31
>>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1080,7 +1080,15 @@ static int linear_read(unsigned long addr, unsigned
>> int bytes, void *p_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 March 2019 11:04
> To: Paul Durrant
> Cc: Andrew Cooper ; Igor Druzhinin
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/hvm: finish IOREQ correctly on comple
>>> On 11.03.19 at 11:49, wrote:
> Am Mon, 11 Mar 2019 04:16:07 -0600
> schrieb "Jan Beulich" :
>
>> >>> On 08.03.19 at 20:20, wrote:
>> > To reiterate the second paragraph: if a domU uses TSC as primary clock
>> > source, it is expected that it runs NTP to cover for the resulting
>> > drift.
>>> On 11.03.19 at 12:09, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 11 March 2019 11:04
>>
>> >>> On 11.03.19 at 11:30, wrote:
>> >> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
>> >> Sent: 08 March 2019 21:31
>> >>
>> >> --- a/xen/arch/x86/hvm/emulate.c
>> >> ++
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 March 2019 11:33
> To: Paul Durrant
> Cc: Andrew Cooper ; Igor Druzhinin
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/hvm: finish IOREQ correctly on comple
Am Mon, 11 Mar 2019 05:19:34 -0600
schrieb "Jan Beulich" :
> >>> On 11.03.19 at 11:49, wrote:
> > I do not see how the HVM domU clock can be without drift if it does not
> > sync with an external source. It seems xenlinux based PV drivers lack
> > a clocksource, so they would better run ntp.
This run is configured for baseline tests only.
flight 83730 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/83730/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Committers,
Please don't push any new patch to staging because we are going to
branch off 4.12 from the main trunk.
Another email will be sent once the moratorium is lifted.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://li
Am Mon, 11 Mar 2019 05:19:34 -0600
schrieb "Jan Beulich" :
> But of course the seemingly
> random 200 will itself need a much better reasoning, or at least a
> clear indication of the data base (number of different systems) that
> it was derived from. "Large number of hosts", after all, may mean 1
flight 133684 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133684/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
test-am
CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
6 ships 2.6.
Bump the version to 2.6 in README. Now that all scripts are 3
compatible, remove the restriction on python 2 as well.
Update the check in configure.ac.
Signed-off-by: Wei Liu
---
README | 10 ++--
Do the following:
1. Change the form of "print".
2. Use AC_CHECK_FUNC to avoid the need to generate library name.
3. Remove unused stuff.
Signed-off-by: Wei Liu
Reviewed-by: Anthony PERARD
---
m4/python_devel.m4 | 23 +++-
tools/configure| 64 +++
Not sure why Python 2 never complained, but Python 3 does.
Change tabs to spaces.
Signed-off-by: Wei Liu
---
Backport candidate.
---
tools/pygrub/src/pygrub | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 52a8965ad9
Run 2to3 and pick the sensible suggestions.
Import print_function and absolute_import so 2.6 can work.
There has never been a curses.wrapper module according to 2.x and 3.x
doc, only a function, so "import curses.wrapper" is not correct. It
happened to work because 2.x implemented a (undocumented
With the help of two porting guides and cpython source code:
1. Use PyBytes to replace PyString counterparts.
2. Use PyVarObject_HEAD_INIT.
3. Remove usage of Py_FindMethod.
4. Use new module initialisation routine.
For #3, Py_FindMethod was removed, yet an alternative wasn't
documented. The cod
Go through transformations suggested by 2to3 and pick the necessary
ones.
Signed-off-by: Wei Liu
---
tools/libxl/gentest.py | 4 +++-
tools/libxl/gentypes.py | 12 +++-
tools/libxl/idl.py | 15 ---
3 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/tools/
Signed-off-by: Wei Liu
---
tools/pygrub/src/fsimage/fsimage.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/tools/pygrub/src/fsimage/fsimage.c
b/tools/pygrub/src/fsimage/fsimage.c
index 743a3fb7b8..780207791c 100644
--- a/tools/pygrub/src/fsimage/fsimage.c
+++ b/tools/pygrub/src/fsim
This series makes tools work with Python 2 and 3
Tested on my testbox with Python 2 and 3. Unfortunately I didn't have a
suitable disk image for pygrub to consume, but at least while running pygrub 2
and 3 it gave the same error message.
Andrew's "tools/xen-foreign: Update python scripts to be
Py
On 11/03/2019 13:04, Wei Liu wrote:
> CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
> 6 ships 2.6.
>
> Bump the version to 2.6 in README. Now that all scripts are 3
> compatible, remove the restriction on python 2 as well.
I think the Python 2 restriction needs to stay unti
On 11/03/2019 13:04, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Good riddance.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/03/2019 13:04, Wei Liu wrote:
> Not sure why Python 2 never complained, but Python 3 does.
>
> Change tabs to spaces.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Tabs vs spaces was an issue with Py2 which got fixed in 3 when it was
fine to break existing scripts.
The problem wa
On 11/03/2019 13:04, Wei Liu wrote:
> Go through transformations suggested by 2to3 and pick the necessary
> ones.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.
On 11/03/2019 13:04, Wei Liu wrote:
> Run 2to3 and pick the sensible suggestions.
>
> Import print_function and absolute_import so 2.6 can work.
>
> There has never been a curses.wrapper module according to 2.x and 3.x
> doc, only a function, so "import curses.wrapper" is not correct. It
> happened
On 11/03/2019 07:14, Juergen Gross wrote:
> Any estimate when we can expect patches? The 4.12 release is pending and
> this is the only remaining regression I'm aware of.
>
> If you tell me there is no reasonable chance of anything acceptable
> being posted this week I'd go on with the release pro
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v5:
- Put the call
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridian/synic.c
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept m
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the un
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch als
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This p
This series adds three new enlightenments:
- Synthetic timers, which depends on the...
- Synthetic interrupt controller (or SynIC)
- Synthetic cluster IPI
All these enlightenments are implemented in current versions of QEMU/KVM
so this series closes the gap.
Paul Durrant (11):
viridian: add in
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
attemp
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only ta
>>> On 11.03.19 at 12:39, wrote:
> Ok, thanks for the clarification. So, the problem is that memory accesses
> are not stashed (understandably I guess) in the mmio_cache. If they were then
> forcing the code down the MMIO path would work. So, what we probably need is
> a cache of all accesses t
>>> On 11.03.19 at 12:57, wrote:
> Am Mon, 11 Mar 2019 05:19:34 -0600
> schrieb "Jan Beulich" :
>
>> Plus - is your change somehow limited to HVM guests? I can't seem to
>> spot why that would be. And if it isn't, then leaving PV guests out of
>> the discussion is simply wrong.
>
> tsc_set_info
>>> On 11.03.19 at 13:09, wrote:
> Am Mon, 11 Mar 2019 05:19:34 -0600
> schrieb "Jan Beulich" :
>
>> But of course the seemingly
>> random 200 will itself need a much better reasoning, or at least a
>> clear indication of the data base (number of different systems) that
>> it was derived from. "L
On Sat, Mar 09, 2019 at 09:37:32AM +0800, Ming Lei wrote:
> xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
> for checking if the two bvecs can be merged, so pass page to
> xen_biovec_phys_mergeable() directly.
Looks fine:
Reviewed-by: Christoph Hellwig
_
On Sat, Mar 09, 2019 at 09:37:33AM +0800, Ming Lei wrote:
> For normal filesystem IO, each page is added via blk_add_page(),
> in which bvec(page) merge has been handled already, and basically
> not possible to merge two adjacent bvecs in one bio.
>
> So not try to merge two adjacent bvecs in blk_
On Mon, Mar 11, 2019 at 01:08:11PM +, Andrew Cooper wrote:
> On 11/03/2019 13:04, Wei Liu wrote:
> > CentOS 5, which was the reason of the 2.4 restriction, is EOL. CentOS
> > 6 ships 2.6.
> >
> > Bump the version to 2.6 in README. Now that all scripts are 3
> > compatible, remove the restrictio
... and drop PY_PAD.
Signed-off-by: Wei Liu
---
This can be squashed into previous patch.
---
tools/pygrub/src/fsimage/fsimage.c | 47 ++
1 file changed, 7 insertions(+), 40 deletions(-)
diff --git a/tools/pygrub/src/fsimage/fsimage.c
b/tools/pygrub/src/fsim
On 11/03/2019 14:41, Wei Liu wrote:
> ... and drop PY_PAD.
>
> Signed-off-by: Wei Liu
Much nicer. With this suitably folded, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/lis
Juergen Gross writes ("Commit moratorium for branching off 4.12"):
> Committers,
>
> Please don't push any new patch to staging because we are going to
> branch off 4.12 from the main trunk.
4.12 is now branched off from the main trunk (ie, staging-4.12 is
branched from staging).
The commit mora
flight 83731 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83731/
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 3/5/19 11:12 AM, Wei Liu wrote:
> On Wed, Feb 27, 2019 at 06:23:35PM +, Woods, Brian wrote:
>> On 2/27/19 7:47 AM, Wei Liu wrote:
>>> On Mon, Feb 25, 2019 at 08:23:58PM +, Woods, Brian wrote:
Some AMD processors can use a mixture of mwait and halt for accessing
various c-states
>>> On 25.02.19 at 16:47, wrote:
> These will be extended with further libx86 work.
>
> Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
> unit tests.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-deve
Provide a rune, following which a magit selective git add
(or git add -p) can be used to commit the appropriate changes.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/
One per line is a lot easier to read.
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/process/release-technician-checklist.txt
b/docs/process/release-technician-checklist.txt
index 5dd85dbc
We no longer use hg
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 4
1 file changed, 4 deletions(-)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/branching-checklist.txt
index 5a02d21968..4cda33656d 100644
--- a/docs/process/branching-checklist.t
It is only necessary to change Config.mk if it refers to unstable
branches anywhere. This time, for example, it didn't.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/process/branching-checklist.txt
b/docs/process/br
In particular, say clearly that X.Y-unstable should be thus, not
X.Y.0-unstable.
CC: Jan Beulich
Signed-off-by: Ian Jackson
---
docs/process/release-technician-checklist.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/docs/process/release-technician-checklist.txt
b
> -Original Message-
> From: Andrew Cooper
> Sent: 08 March 2019 17:10
> To: Jan Beulich ; Paul Durrant
> Cc: Roger Pau Monne ; Wei Liu ;
> xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH 6/6] x86: introduce dr_mask_idx() helper function...
>
> On 08/03/2019 16:58, Jan Beuli
>>> On 27.02.19 at 13:31, wrote:
> On Mon, Feb 25, 2019 at 03:47:13PM +, Andrew Cooper wrote:
>> +
>> +switch ( data.idx )
>> +{
>> +/*
>> + * Assign data.val to 'field', checking for truncation if the
>> + * backing storage for 'field' is sm
>>> On 27.02.19 at 13:31, wrote:
> On Mon, Feb 25, 2019 at 03:47:14PM +, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> Signed-off-by: Sergey Dyasli
>> Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Wei Liu
Acked-by: Jan Beulich
__
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 March 2019 16:40
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu
> ; Jun Nakajima ; Kevin Tian
> ; xen-
> devel
> Subject: Re: [PATCH 1/6] x86: stop handling MSR_IA32_BNDCFGS save/restore
>>> On 11.03.19 at 16:28, wrote:
> In particular, say clearly that X.Y-unstable should be thus, not
> X.Y.0-unstable.
>
> CC: Jan Beulich
> Signed-off-by: Ian Jackson
Thanks! In case it matters / helps:
Acked-by: Jan Beulich
Jan
___
Xen-devel ma
>>> On 11.03.19 at 17:10, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 08 March 2019 16:40
>>
>> >>> On 07.01.19 at 13:02, wrote:
>> > @@ -3472,12 +3494,6 @@ int hvm_msr_read_intercept(unsigned int msr,
>> > uint64_t *msr_content)
>> > *msr_content = v->arch.hvm.msr_
The flag is really only meant for those, both HVM and 32-bit PV tell
kernel from user mode based on CPL/RPL. Remove the all-question-marks
comment and let's be on the safe side here and also suppress clearing
for 32-bit PV (this isn't a fast path after all).
Remove no longer necessary is_pv_32bit_
Add model 0x86 to relevant switch() statements, as per SDM 069 Vol 4.
Take the liberty and also change Gemini Lake comments to say Goldmont
Plus. to match the SDM.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -224,6 +224,8 @@ static void do_
This is needed for Dom0 creation only, therefore it gets additionally
framed by an #ifdef.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -950,7 +950,9 @@ int paging_write_p2m_entry(struct p2m_do
return rc;
}
-int paging_set_allocation(struct
-Original Message-
> On 27.11.18 17:32, Kazuhito Hagio wrote:
> >> Linux marks pages that are logically offline via a page flag (map count).
> >> Such pages e.g. include pages infated as part of a balloon driver or
> >> pages that were not actually onlined when onlining the whole section.
>
1: events: drop arch_evtchn_inject()
2: common: avoid atomic read-modify-write accesses in map_vcpu_info()
3: Arm/atomic: correct asm() constraints in build_add_sized()
4: Arm/atomic: drop uniformly used reg macro parameters
5: Arm/atomic: parameterize register modifier macro arguments
6: Arm/atomi
Have the only user call vcpu_mark_events_pending() instead, at the same
time arranging for correct ordering of the writes (evtchn_pending_sel
should be written before evtchn_upcall_pending).
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -597,11 +597,6 @@ out:
There's no need to set the evtchn_pending_sel bits one by one. Simply
write full words with all ones.
For Arm this requires extending write_atomic() to also handle 64-bit
values; for symmetry read_atomic() gets adjusted as well.
Signed-off-by: Jan Beulich
--- a/xen/common/domain.c
+++ b/xen/com
1 - 100 of 157 matches
Mail list logo
