On 20.10.2020 20:46, Andrew Cooper wrote:
> On 20/10/2020 18:10, Andrew Cooper wrote:
>> On 20/10/2020 17:20, Andrew Cooper wrote:
>>> On 20/10/2020 16:48, Jan Beulich wrote:
On 20.10.2020 17:24, Andrew Cooper wrote:
> With MMU_UPDATE, a PV guest can make changes to higher level pagetables
flight 156031 xen-4.14-testing real [real]
flight 156062 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156031/
http://logs.test-lab.xenproject.org/osstest/logs/156062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 20.10.2020 17:24, Andrew Cooper wrote:
> A couple of minor points.
>
> * PV guests can create global mappings. I can't reason any safe way to relax
>FLUSH_TLB_GLOBAL to just FLUSH_TLB.
We only care about guest view here, and from guest view we only
care about non-leaf entries. Non-leaf e
flight 156040 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156030 xen-4.13-testing real [real]
flight 156052 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156030/
http://logs.test-lab.xenproject.org/osstest/logs/156052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 156047 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156047/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- use oneline comments even for nested struct members
- remove redundant "EVTCHNOP_status:" prefix
---
xen/include/public/event_channel.h | 184 ++---
1 f
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove "enum" comments
- use oneline comments even for nested struct members
---
xen/include/public/xen.h | 566 +--
1 file changed, 369 ins
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove "enum" comments
---
xen/include/public/sched.h | 134 +
1 file changed, 92 insertions(+), 42 deletions(-)
diff --git a/xen/include/p
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove "enum" comments
- fix line too long
- remove stray blank line
---
xen/include/public/memory.h | 236
1 file changed, 156 insertions(
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/elfnote.h | 109 ++-
1 file changed, 81 insertions(+), 28 deletions(-)
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/device_tree_defs.h | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/xen/include/public/device_tree_defs.h
b/xen/include/public/
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hypfs.h | 72 --
1 file changed, 45 insertions(+), 27 deletions(-)
diff --git a/xen/include/public/hypfs.h b/xen/include/public/hypfs.h
i
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hvm/params.h | 153 +---
1 file changed, 120 insertions(+), 33 deletions(-)
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove "- XENVER_{version,pagesize}"
---
xen/include/public/version.h | 73 +---
1 file changed, 59 insertions(+), 14 deletions(-)
diff --git a
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/vcpu.h | 180 --
1 file changed, 136 insertions(+), 44 deletions(-)
diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h
in
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hvm/hvm_op.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index
Hi all,
This patch series converts Xen in-code comments to the kernel-doc (and
doxygen) format:
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
Please note that this patch series is meant as groundwork. The end goal
is to enable a more sophisticated documents generation with dox
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/arch-arm.h | 43 ++-
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-a
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove "enum" comments
- typedef grant_ref_t in the comment
- remove "New guests should use version 2."
- remove two redundant blanks
---
xen/include/public/grant_table.h | 447
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/features.h | 78 ++-
1 file changed, 59 insertions(+), 19 deletions(-)
diff --git a/xen/include/public/features.h b/xen/include/public/featur
flight 156027 xen-unstable real [real]
flight 156048 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156027/
http://logs.test-lab.xenproject.org/osstest/logs/156048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 20/10/2020 18:10, Andrew Cooper wrote:
> On 20/10/2020 17:20, Andrew Cooper wrote:
>> On 20/10/2020 16:48, Jan Beulich wrote:
>>> On 20.10.2020 17:24, Andrew Cooper wrote:
With MMU_UPDATE, a PV guest can make changes to higher level pagetables.
This
is from Xen's point of view (
On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if
On 10/5/20 2:15 PM, David Hildenbrand wrote:
As we no longer shuffle via generic_online_page() and when undoing
isolation, we can simplify the comment.
We now effectively shuffle only once (properly) when onlining new
memory.
Reviewed-by: Wei Yang
Acked-by: Michal Hocko
Acked-by: Vlastimil
On 10/5/20 2:15 PM, David Hildenbrand wrote:
Whenever we move pages between freelists via move_to_free_list()/
move_freepages_block(), we don't actually touch the pages:
1. Page isolation doesn't actually touch the pages, it simply isolates
pageblocks and moves all free pages to the MIGRATE_I
On 10/5/20 2:15 PM, David Hildenbrand wrote:
__putback_isolated_page() already documents that pages will be placed to
the tail of the freelist - this is, however, not the case for
"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
the case for all existing users.
This change a
Hi Paul,
On 19/10/2020 08:23, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 16 October 2020 16:47
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Paul Durrant ; Daniel De Graaf
; Ian Jackson
; Wei Liu ; Andrew Cooper
; George Dunlap
; Jan Beulich ; Stefano Stab
Hi,
On 19/10/2020 19:07, Stefano Stabellini wrote:
On Fri, 16 Oct 2020, Artem Mygaiev wrote:
-Original Message-
From: Julien Grall
Sent: пятница, 16 октября 2020 г. 13:24
To: Anastasiia Lukianenko ; jbeul...@suse.com;
george.dun...@citrix.com
Cc: Artem Mygaiev ; vicooo...@gmail.com;
On 20/10/2020 17:20, Andrew Cooper wrote:
> On 20/10/2020 16:48, Jan Beulich wrote:
>> On 20.10.2020 17:24, Andrew Cooper wrote:
>>> With MMU_UPDATE, a PV guest can make changes to higher level pagetables.
>>> This
>>> is from Xen's point of view (as the update only affects guest mappings), and
>
Hi Rahul,
Thank you for the contribution. Lets make sure this attempt to SMMUv3
support in Xen will be more successful than the other one :).
I haven't reviewed the code yet, but I wanted to provide feedback on the
commit message.
On 20/10/2020 16:25, Rahul Singh wrote:
Add support for ARM
The pull request you sent on Tue, 20 Oct 2020 14:09:56 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.10b-rc1b-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4a5bb973fa0353d25dbe854694c71bb58eb4cf78
Thank you!
--
Deet-doot-dot,
flight 156020 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 20/10/2020 16:48, Jan Beulich wrote:
> On 20.10.2020 17:24, Andrew Cooper wrote:
>> With MMU_UPDATE, a PV guest can make changes to higher level pagetables.
>> This
>> is from Xen's point of view (as the update only affects guest mappings), and
>> the guest is required to flush suitably after
flight 156028 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156028/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On 20.10.2020 17:24, Andrew Cooper wrote:
> With MMU_UPDATE, a PV guest can make changes to higher level pagetables. This
> is from Xen's point of view (as the update only affects guest mappings), and
> the guest is required to flush suitably after making updates.
>
> However, Xen's use of linear
On Tue, Oct 20, 2020 at 11:40 AM Anthony PERARD
wrote:
>
> On Mon, Oct 19, 2020 at 04:00:50PM -0400, Jason Andryuk wrote:
> > The device model state saved by QMP xen-save-devices-state doesn't
> > include the vmdesc json. When restoring an HVM, xen-load-devices-state
> > always triggers "Expected
On 20/10/2020 16:24, Andrew Cooper wrote:
> With MMU_UPDATE, a PV guest can make changes to higher level pagetables. This
> is from Xen's point of view (as the update only affects guest mappings), and
> the guest is required to flush suitably after making updates.
>
> However, Xen's use of linear
On Mon, Oct 19, 2020 at 04:00:50PM -0400, Jason Andryuk wrote:
> The device model state saved by QMP xen-save-devices-state doesn't
> include the vmdesc json. When restoring an HVM, xen-load-devices-state
> always triggers "Expected vmdescription section, but got 0". This is
> not a problem when
Hi Jan,
On 20/10/2020 16:05, Jan Beulich wrote:
On 20.10.2020 17:00, Julien Grall wrote:
On 20/10/2020 14:52, Jan Beulich wrote:
While the flush coalescing optimization has been helping the non-shared
case, it has actually lead to double flushes in the shared case (which
ought to be the more c
Add support for ARM architected SMMUv3 implementations. It is based on
the Linux SMMUv3 driver.
Major differences between the Linux driver are as follows:
1. Only Stage-2 translation is supported as compared to the Linux driver
that supports both Stage-1 and Stage-2 translations.
2. Use P2M pa
With MMU_UPDATE, a PV guest can make changes to higher level pagetables. This
is from Xen's point of view (as the update only affects guest mappings), and
the guest is required to flush suitably after making updates.
However, Xen's use of linear pagetables (UPDATE_VA_MAPPING, GNTTABOP_map,
writea
flight 156029 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156029/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20.10.2020 17:00, Julien Grall wrote:
> On 20/10/2020 14:52, Jan Beulich wrote:
>> While the flush coalescing optimization has been helping the non-shared
>> case, it has actually lead to double flushes in the shared case (which
>> ought to be the more common one nowadays at least): Once from
>>
Hi Jan,
On 20/10/2020 14:52, Jan Beulich wrote:
While the flush coalescing optimization has been helping the non-shared
case, it has actually lead to double flushes in the shared case (which
ought to be the more common one nowadays at least): Once from
*_set_entry() and a second time up the call
On 29.05.2020 12:30, Jan Beulich wrote:
> On 29.05.2020 12:07, Andrew Cooper wrote:
>> On 29/05/2020 10:34, Jan Beulich wrote:
>>> While the behavior to ignore this option without FLASK support was
>>> properly documented, it is still somewhat surprising to someone using
>>> this option and then st
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly). The present callbacks don't
(and no such callback should) have any need for the lock to be held.
Signed-off-by:
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this i
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(so far by means of a barrier). To facilitate the conversion, switch to
an ordinary write locked region in evtchn_close().
Signed-off-by: Jan Beulich
---
v2:
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
is zero, provide sufficient guarantees. Undo the lock addition done for
XSA-343 (commit e045199c7c9c "evtchn: address races with
evtchn_reset()"). Update
On 10/19/20 4:05 PM, Jason Gunthorpe wrote:
> On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
>> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>>> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
From: Tom Rix
This is a upcoming change to clean
The function isn't about an "event" in general, but about a vIRQ. The
function also failed to honor global vIRQ-s, instead assuming the caller
would pass vCPU 0 in such a case.
While at it also adjust the
- types the function uses,
- single user to make use of domain_vcpu().
Signed-off-by: Jan Be
Some lock wants to be held to make sure the port doesn't change state,
but there's no point holding the per-domain event lock here. Switch to
using the finer grained per-channel lock instead.
FAOD this doesn't guarantee anything towards in particular
evtchn_fifo_set_pending(), as for interdomain c
Having a FIFO specific header is not (or at least no longer) warranted
with just three function declarations left there. Introduce a private
header instead, moving there some further items from xen/event.h.
Signed-off-by: Jan Beulich
---
v2: New.
---
TBD: If - considering the layering violation t
There's no global lock around the updating of this global piece of data.
Make use of cmpxchgptr() to avoid two entities racing with their
updates.
While touching the functionality, mark xen_consumers[] read-mostly (or
else the if() condition could use the result of cmpxchgptr(), writing to
the slo
These are grouped into a series largely because of their origin,
not so much because there are heavy dependencies among them.
Compared to v1, besides there being 3 new patches, some
re-ordering has been done; in particular the last patch isn't
ready yet, but I still wanted to include it to have a c
On 10/19/20 12:42 PM, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
>>> From: Tom Rix
>>>
>>> This is a upcoming change to clean up a new warning treewide.
>>> I am wondering if the change could be o
Fill the new page table _before_ installing into a live page table
hierarchy, as installing a blank page first risks I/O faults on
sub-ranges of the original super page which aren't part of the range
for which mappings are being updated.
While at it also do away with mapping and unmapping the same
While the flush coalescing optimization has been helping the non-shared
case, it has actually lead to double flushes in the shared case (which
ought to be the more common one nowadays at least): Once from
*_set_entry() and a second time up the call tree from wherever the
overriding flag gets played
The set of systems affected by XSA-345 would have been smaller is we had
this in place already: When the processor is capable of dealing with
mismatched cacheability, there's no extra work we need to carry out.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -795,6
Am 20.10.20 um 14:20 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
On 16.10.2020 10:53, Juergen Gross wrote:
> Actions in NMI context are rather limited as e.g. locking is rather
> fragile.
>
> Add a generic framework to continue processing in normal interrupt
> context after leaving NMI processing.
>
> This is done by a high priority interrupt vector triggered
On Tue, May 26, 2020 at 10:13 AM Ian Jackson wrote:
>
> Jason Andryuk writes ("[PATCH] SUPPORT: Add linux device model stubdom to
> Toolstack"):
> > Add qemu-xen linux device model stubdomain to the Toolstack section as a
> > Tech Preview.
>
> Acked-by: Ian Jackson
Hi, this never got applied.
> On 19 Oct 2020, at 18:37, Stefano Stabellini wrote:
>
> On Fri, 16 Oct 2020, Bertrand Marquis wrote:
>> If for some reason the hardware reset is not working, print a message to
>> the user every 5 seconds to warn him that the system did not reset
>> properly and Xen is still looping.
>>
>>
Files in the bash-completion dirs should be named like the commands,
without suffix. Without this change 'xl' will not be recognized as a
command with completion support if BASH_COMPLETION_DIR is set to
/usr/share/bash-completion/completions.
Fixes commit 9136a919b19929ecb242ef327053d55d824397df
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either sys
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-bu
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drive
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Teste
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and wri
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modi
flight 156025 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156013 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156013/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine 4 memdisk-try-append fail pass in 155973
Tests which did not succeed, but
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.10b-rc1b-tag
xen: branch for v5.10-rc1b
It contains the following:
- A single patch for fixing the Xen security issue XSA-331 (malicious
guests can DoS dom0 by triggering NULL-po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-346
version 2
undue deferral of IOMMU TLB flushes
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
To effi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-347
version 2
unsafe AMD IOMMU page table updates
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
AMD IOM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-331
version 2
Race condition in Linux event handler may crash dom0
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-332
version 3
Rogue guests can cause DoS of Dom0 via high frequency events
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-345
version 3
x86: Race condition in Xen mapping code
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
The X
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 15 October 2020 17:44
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu ; George Dunlap
> ; Ian Jackson
> ; Julien Grall ; Stefano Sta
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 15 October 2020 17:44
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ;
> Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Jan Beulich ; Wei Liu
>
During 'xl -v.. migrate domU host' a large amount of debug is generated.
It is difficult to map each line to the sending and receiving side.
Also the time spent for migration is not reported.
With 'xl migrate -T domU host' both sides will print timestamps and
also the pid of the invoked xl process
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 15 October 2020 17:44
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu ; Julien Grall
> ; Stefano Stabellini
> ; Julien Grall
> Subj
> -Original Message-
> From: Jan Beulich
> Sent: 20 October 2020 11:05
> To: p...@xen.org
> Cc: 'Oleksandr Tyshchenko' ;
> xen-devel@lists.xenproject.org; 'Oleksandr
> Tyshchenko' ; 'Andrew Cooper'
> ; 'Roger Pau
> Monné' ; 'Wei Liu' ; 'Julien Grall'
> ; 'Stefano
> Stabellini' ; 'Julien
On 20.10.2020 12:01, Julien Grall wrote:
>
>
> On 20/10/2020 10:34, Jan Beulich wrote:
>> On 20.10.2020 11:25, Julien Grall wrote:
>>> Given that evtchn->last_vcpu_id and evtchn->last_priority can only be
>>> modified in evtchn_fifo_set_pending(), this suggests that it is expected
>>> for the fun
On 20.10.2020 11:14, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of
>> Oleksandr Tyshchenko
>> Sent: 15 October 2020 17:44
>>
>> --- a/xen/include/asm-x86/hvm/ioreq.h
>> +++ b/xen/include/asm-x86/hvm/ioreq.h
>> @@ -181,6 +181,8 @@ static inline bool arch_hvm_ioreq_destroy(struct domain
>> *
On 20/10/2020 10:34, Jan Beulich wrote:
On 20.10.2020 11:25, Julien Grall wrote:
Given that evtchn->last_vcpu_id and evtchn->last_priority can only be
modified in evtchn_fifo_set_pending(), this suggests that it is expected
for the function to multiple called concurrently on the same event ch
flight 156022 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
QEMU upstream now requires ninja to build. (Probably since QEMU commit
09e93326e448 ("build: replace ninjatool with ninja"))
Signed-off-by: Anthony PERARD
---
ts-xen-build-prep | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index fcabf75
On 20.10.2020 11:25, Julien Grall wrote:
> Hi Jan,
>
> On 16/10/2020 13:09, Jan Beulich wrote:
>> On 16.10.2020 11:36, Julien Grall wrote:
>>> On 15/10/2020 13:07, Jan Beulich wrote:
On 14.10.2020 13:40, Julien Grall wrote:
> On 13/10/2020 15:26, Jan Beulich wrote:
>> On 13.10.2020 16
On 16.10.2020 12:58, Juergen Gross wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -660,11 +660,12 @@ void pv_shim_inject_evtchn(unsigned int port)
> if ( port_is_valid(guest, port) )
> {
> struct evtchn *chn = evtchn_from_port(guest, port);
> -u
Hi Jan,
On 16/10/2020 13:09, Jan Beulich wrote:
On 16.10.2020 11:36, Julien Grall wrote:
On 15/10/2020 13:07, Jan Beulich wrote:
On 14.10.2020 13:40, Julien Grall wrote:
On 13/10/2020 15:26, Jan Beulich wrote:
On 13.10.2020 16:20, Jürgen Groß wrote:
Especially Julien was rather worried by t
flight 156017 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156017/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f82b827c92f77eac8debdce6ef9689d156771871
baseline version:
ovmf 29d14d3a30fdfbe017d39
> -Original Message-
> From: Xen-devel On Behalf Of
> Oleksandr Tyshchenko
> Sent: 15 October 2020 17:44
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu ; Julien Grall
> ; Stefano Stabellin
> -Original Message-
> From: Xen-devel On Behalf Of
> Oleksandr Tyshchenko
> Sent: 15 October 2020 17:44
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu ; Julien Grall
> ; Stefano Stabellin
1 - 100 of 111 matches
Mail list logo
