At 02:28 -0700 on 18 Dec (1513564115), Jan Beulich wrote:
> shadow_one_bit_enable() sets PG_SH_enable (if not already set of course)
> in addition to the bit being requested. Make shadow_one_bit_disable()
> behave similarly - clear PG_SH_enable if that's the only bit remaining.
>
> Signed-off-by:
At 08:04 -0700 on 12 Dec (1513065884), Jan Beulich wrote:
> PV guests don't ever get shadowed in other than 4-level mode anymore;
> commit 5a3ce8f85e ("x86/shadow: drop stray name tags from
> sh_{guest_get,map}_eff_l1e()") didn't go quite fare enough (and there's
> a good chance that further cleanu
At 08:05 -0700 on 12 Dec (1513065939), Jan Beulich wrote:
> The vCPU count can be had more directly.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
> In the sh_make_shadow() case the question is whether it really was
> intended to count all vCPU-s, rather than e.g. only all initialized
>
At 08:07 -0700 on 12 Dec (1513066056), Jan Beulich wrote:
> Utilize as many of the bits available in the union as possible, without
> (just to be on the safe side) colliding with any of the bits outside of
> PGT_type_mask.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
At 08:06 -0700 on 12 Dec (1513065979), Jan Beulich wrote:
> Following what we've already done in the XSA-250 fix, convert another
> sh_pin() caller to no longer fail the higher level operation if pinning
> fails, as pinning is a performance optimization only in those places.
>
> Suggested-by: Tim
At 08:08 -0700 on 12 Dec (1513066100), Jan Beulich wrote:
> Stop open-coding SHARED_M2P() and drop a pointless use of it from
> paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and
> another one from free_page_type() (prior assertions render this
> redundant).
>
> Signed-off-by:
At 08:09 -0700 on 12 Dec (1513066153), Jan Beulich wrote:
> ... in preference over paging_mark_dirty(), when the PFN is known
> anyway.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
http
On 20/12/17 00:27, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
>
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running on the same virtual OS p
On 12/20/2017 01:27 AM, Dongwon Kim wrote:
This patch series contains the implementation of a new device driver,
hyper_dmabuf, which provides a method for DMA-BUF sharing across
different OSes running on the same virtual OS platform powered by
a hypervisor.
This is very interesting at least in
>>> On 19.12.17 at 01:42, wrote:
> This patch implements get HW info flow for MBA including its callback
> function and sysctl interface.
>
> Signed-off-by: Yi Sun
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 117315 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
116619
test-amd
>>> On 19.12.17 at 01:42, wrote:
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel Memory Bandwidth Allocation (MBA) to Xen.
>
> Besides the MBA enabling, we change some interfaces to make them more
> general but not only for CAT.
>
> The first 5 patches of V9 haven
There's no need for
- advancing the handles and at the same time using
__copy_{from,to}_guest_offset(),
- an "out" label,
- local variables "done" and (function scope) "rc".
To better reflect its resulting use also rename the function's "start"
parameter to "extent".
Signed-off-by: Jan Beulich
1: PoD: correctly handle non-order-0 decrease-reservation requests
2: p2m: force return value checking of p2m_set_entry()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinf
p2m_pod_decrease_reservation() at the moment only returns a boolean
value: true for "nothing more to do", false for "something more to do".
If it returns false, decrease_reservation() will loop over the entire
range, calling guest_remove_page() for each page.
Unfortunately, in the case p2m_pod_dec
As XSAs 246 and 247 have shown, not doing so is rather dangerous.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Reviewed-by: Kevin Tian
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1550,9 +1550,11 @@ void p2m_mem_paging_populate(struct doma
if ( p2mt == p2m_ram_pag
The parts of this series aren't really dependent upon one another,
they belong together solely because of their origin.
1: x86/shadow: widen reference count
2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
3: x86: use paging_mark_pfn_dirty()
Signed-off-by: Jan Beulich
_
Utilize as many of the bits available in the union as possible, without
(just to be on the safe side) colliding with any of the bits outside of
PGT_type_mask.
Note that the first and last hunks of the xen/include/asm-x86/mm.h
change are merely code motion.
Signed-off-by: Jan Beulich
Acked-by: Ti
... in preference over paging_mark_dirty(), when the PFN is known
anyway.
Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -219,14 +219,12 @@ static int modified_memory(struct domain
page = get_page_from_gfn(d, pfn, NULL, P2
Stop open-coding SHARED_M2P() and drop a pointless use of it from
paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and
another one from free_page_type() (prior assertions render this
redundant).
Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
---
v2: Re-do free_page_type() chan
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 December 2017 09:42
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH v2 3/3] x86: use paging_mark_pfn_dirty()
>
> ... in preference over paging_mark_dirty(), when the PFN
flight 117352 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117352/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
>
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running o
>>> On 19.12.17 at 01:42, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -260,17 +260,17 @@ QEMU_TRADITIONAL_REVISION ?= $(QEMU_TAG)
> endif
>
> ifeq ($(GIT_HTTP),y)
> -OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
> -QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-
On 19/12/17 07:31, Adi Pircalabu wrote:
> Posted initially to centos-virt mailing list. Please note I'm not
> subscribed to xen-devel.
>
> Running "xl -v vcpu-set " on both CentOS 6 running
> 4.14.5-1.el6.elrepo.x86_64 and CentOS 7 running
> 4.14.5-1.el7.elrepo.x86_64 I'm able to trigger this bug
flight 117377 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117377/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 1b33150fe06ab9217f7f12b01bc5e607f4f55658
baseline version:
xen ec32
On 20/12/17 09:18, Jan Beulich wrote:
> There's no need for
> - advancing the handles and at the same time using
> __copy_{from,to}_guest_offset(),
> - an "out" label,
> - local variables "done" and (function scope) "rc".
>
> To better reflect its resulting use also rename the function's "start"
On Tue, Dec 19, 2017 at 05:20:41PM +0100, Juergen Gross wrote:
> On 19/12/17 17:11, Roger Pau Monné wrote:
> > On Tue, Dec 19, 2017 at 04:46:37PM +0100, Juergen Gross wrote:
> >> On 19/12/17 16:38, Roger Pau Monné wrote:
> >>> On Fri, Dec 01, 2017 at 03:14:07PM +0100, Juergen Gross wrote:
> In
flight 117316 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117316/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 117233
test-armhf-armhf-libvirt 14 saveresto
Along with c/s d7128e735031 switching the runtime choice of best nops, switch
the compile-time default to P6 nops. This is more efficient on most
processors for alternative points which add/remove code, rather than switch
between two different pieces of code.
Signed-off-by: Andrew Cooper
---
CC:
flight 117372 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 117339
Tests which
flight 73098 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73098/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i3
>>> On 20.12.17 at 13:04, wrote:
> Along with c/s d7128e735031 switching the runtime choice of best nops, switch
> the compile-time default to P6 nops. This is more efficient on most
> processors for alternative points which add/remove code, rather than switch
> between two different pieces of co
Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
reservation") left host memory not assigned to dom0 as available for
memory hotplug.
Unfortunately this also meant that those regions could be used by
others. Specifically, commit fa564ad96366 ("x86/PCI: Enable a 64bit BAR
on AMD
All,
with the goal of releasing relatively soon after New Year, please
point out backport candidates you find missing from the respective
staging branches, but which you consider relevant.
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproj
flight 117335 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117335/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 117236
test-amd64-amd64-xl-qemuu-win7-amd6
>>> On 18.10.17 at 13:40, wrote:
> Changes since v6:
> - Reduce the output of the debug keys.
> - Fix comments and code to match in vpci_msix_control_write.
> - Optimize size of the MSIX structure.
> - Convert vpci_msix_mem to a uint32_t in order to reduce the size of
>vpci_msix. Introduce
Hi, all!
While trying to reboot a domain which has iomem configured
(we are passing through some devices), I found an issue,
that after domain reboot those iomem's are incorrectly re-mapped,
e.g. for the configuration snippet below fe960 -> 0.
Part of the domain config I use:
iomem=[
"0xfd01
>>> On 15.12.17 at 11:41, wrote:
> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> +
> +if ( iorp->page )
> +{
> +/*
> + * If a guest frame has already been mapped (which may h
>>> On 21.11.17 at 16:19, wrote:
> From: Wolfram Strepp
>
> Furthermore, notice that the initial checks:
>
> if (!node->rb_left)
> child = node->rb_right;
> else if (!node->rb_right)
> child = node->rb_left;
> else
>
>>> On 21.11.17 at 16:19, wrote:
> From: Michel Lespinasse
>
> Empty nodes have no color. We can make use of this property to simplify
> the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE macros. Also,
> we can get rid of the rb_init_node function which had been introduced by
> commit 88d
>>> On 21.11.17 at 16:19, wrote:
> From: Michel Lespinasse
>
> rbtree users must use the documented APIs to manipulate the tree
> structure. Low-level helpers to manipulate node colors and parenthood are
> not part of that API, so move them to lib/rbtree.c
>
> Signed-off-by: Michel Lespinasse
>>> On 21.11.17 at 16:19, wrote:
> From: Michel Lespinasse
>
> It is a well known property of rbtrees that insertion never requires more
> than two tree rotations. In our implementation, after one loop iteration
> identified one or two necessary tree rotations, we would iterate and look
> for m
>>> On 21.11.17 at 16:19, wrote:
> From: Michel Lespinasse
>
> The root node of an rbtree must always be black. However,
> rb_insert_color() only needs to maintain this invariant when it has been
> broken - that is, when it exits the loop due to the current (red) node
> being the root. In all
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> In __rb_erase_color(), we were always setting a node to black after
> exiting the main loop. And in one case, after fixing up the tree to
> satisfy all rbtree invariants, we were setting the current node to root
> just to guarantee
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> In __rb_erase_color(), we have to select one of 3 cases depending on the
> color on the 'other' node children. If both children are black, we flip a
> few node colors and iterate. Otherwise, we do either one or two tree
> rotations
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> In __rb_erase_color(), we often already have pointers to the nodes being
> rotated and/or know what their colors must be, so we can generate more
> efficient code than the generic __rb_rotate_left() and __rb_rotate_right()
> function
>>> On 21.11.17 at 16:19, wrote:
> From: Michel Lespinasse
>
> - Use the newly introduced rb_set_parent_color() function to flip the color
> of nodes whose parent is already known.
> - Optimize rb_parent() when the node is known to be red - there is no need
> to mask out the color in that ca
On 20/12/17 15:05, Boris Ostrovsky wrote:
> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
> reservation") left host memory not assigned to dom0 as available for
> memory hotplug.
>
> Unfortunately this also meant that those regions could be used by
> others. Specifically, co
Hi,
I've been working on transitioning a number of Windows guests under HVM
from using QEMU traditional to QEMU upstream as is recommended in the
documentation. When I move these guests, the PCI subtree for Xen
devices changes and Windows creates a totally new copy of each device.
Windows tracks
On Fri, Dec 8, 2017 at 9:17 PM, Kevin Stange wrote:
> Hi,
>
> I've been running Xen 4.4 stably for some time under kernel 4.9 in dom0
> on CentOS 6 and have been trying to finally move my environment up to
> Xen 4.6 or 4.8 using CentOS 7. Since I've built out my test server with
> Xen 4.6, I've b
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 20 December 2017 16:35
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ; JulienGrall
> ; xen-d
On Wed, Dec 20, 2017 at 5:40 PM, Kevin Stange wrote:
> Hi,
>
> I've been working on transitioning a number of Windows guests under HVM
> from using QEMU traditional to QEMU upstream as is recommended in the
> documentation. When I move these guests, the PCI subtree for Xen
> devices changes and W
flight 117345 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117345/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-libvi
spin_unlock() has full barrier semantics already.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/mcheck/mctelem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/arch/x86/cpu/mcheck/mctelem.c
b/xen/arch/x86/cpu/mcheck/mctelem.c
index 492e2af..35431df 100644
---
On 06/12/17 16:18, Jan Beulich wrote:
> None of the models MISC_ENABLE MSR access is excluded for support 64-bit
> mode - drop the conditional from early_init_intel(). Also convert
> pointless rdmsr_safe() elsewhere to rdmsrl().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 07/12/17 10:05, Jan Beulich wrote:
> Permissions that had been granted before should not be revoked when
> handling unrelated errors.
>
> Reported-by: HW42
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@l
On 12/12/17 14:21, Jan Beulich wrote:
On 12.12.17 at 12:18, wrote:
>> On 12/12/17 11:10, Jan Beulich wrote:
>>> The bounds check needs to be done after the increment, not before, or
>>> else it needs to use a one lower immediate. Also use word operations
>>> rather than byte ones for both the
Hi all,
I experienced the following bug whilst using a Xen VM. What happened was
that this morning a single Xen VM suddenly terminated without cause with the
following being logged in dmesg.
Only 1 VM experienced an issue (out of 2 which were running), the other
remained up and fully functional
Den 18. des. 2017 19:33, skrev Govinda Tatti:
Are you saying do_flr doesn't exist at all in any version of Linux,
and as such the line you're removing is currently pointless?
>>> Yes, that's correct. In other-words, it will not break any existing code
>>> or functionality.
>> Except for
This run is configured for baseline tests only.
flight 73118 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Hi,
my system is:
- amd64
- xen from Debian 9 (stable), package versions 4.8.2+xsa245-0+deb9u1
- home-build kernel Linux 4.14.8 (I believe I saw this with something
like 4.14.1, but I didn't get the logs at that point and had no time
to investigate, so I just reverted to 4.13.16).
- all DomUs
flight 117375 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117375/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check
flight 117359 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 115643
test-amd64-i386-qem
On 17-12-20 03:32:23, Jan Beulich wrote:
> >>> On 19.12.17 at 01:42, wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -260,17 +260,17 @@ QEMU_TRADITIONAL_REVISION ?= $(QEMU_TAG)
> > endif
> >
> > ifeq ($(GIT_HTTP),y)
> > -OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
> >
flight 117365 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117365/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
117311
Tests which
Hi,
I am trying to boot Xen on TX2. But I got a problem with loading domain0
kernel. Hope somebody could help me.
I compiled the Xen 4.9.1 on Jetson TX2. The domain0 kernel version is 4.4.38. I
made some modifications to the device tree provided by the TX2. Then I can boot
xen hypervisor, but
This run is configured for baseline tests only.
flight 73136 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73136/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 117378 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
69 matches
Mail list logo
