>>> On 14.02.18 at 05:03, wrote:
> On on IBRS available env, bootup panic when bti=0 like below:
>
> (XEN) Speculative mitigation facilities:
> (XEN) Hardware features: SMEP IBRS/IBPB STIBP
> (XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
> (XEN) [ Xen-4.4.4OVM x86_64 debug=n Taint
On 13/02/18 20:45, Andrew Cooper wrote:
> The current XPTI implementation isolates the directmap (and therefore a lot of
> guest data), but a large quantity of CPU0's state (including its stack)
> remains visible.
>
> Furthermore, an attacker able to read .text is in a vastly superior position
> t
flight 119091 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119091/
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 in 119060 REGR. vs.
115539
Tests which are fa
Hi Jan,
2018-02-13 23:26 GMT+08:00 Jan Beulich :
On 13.02.18 at 16:15, wrote:
>> I've updated the comments according to your previous suggestions,
>> do they look good to you?
>
> The one in the public header is way too verbose. I specifically don't
> see why you would need to spell out XSM
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org
flight 119138 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 119098
Tests which
On on IBRS available env, bootup panic when bti=0 like below:
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: SMEP IBRS/IBPB STIBP
(XEN) BTI mitigations: Thunk N/A, Others: IBRS- SMEP
(XEN) [ Xen-4.4.4OVM x86_64 debug=n Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e
flight 119072 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken in 119023
build-armhf-pvops5
Created shutdown.c for the shutdown thread and all the shutdown related
functions.
Signed-off-by: Bruno Alvisio
---
Changesd since v1:
* Updated license to a BSD 3-clause. This license was taken
from the updated original file. (Repo: sysml/mini-os)
---
Makefile | 1 +
include/shut
Signed-off-by: Bruno Alvisio
---
Changed since v1:
* Removed resume/suspend_time() and used init/fini_time() instead
---
arch/x86/time.c | 1 -
kernel.c| 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/time.c b/arch/x86/time.c
index 3658142..8077c80 10064
For mini-OS to support suspend and restore, the kernel will have to suspend
different modules such as xenbus, console, irq, etc. During save/restore the
kernel and arch pre_suspend and post_suspend functions will be invoked to
suspend/resume each of the modules.
Signed-off-by: Bruno Alvisio
Revie
Performed an additional cleanup to make the file more syntactically consistent.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
include/netfront.h | 8 +-
kernel.c | 8 ++
netfront.c | 309 ++---
3 files changed
Signed-off-by: Bruno Alvisio
---
Changed since v1:
- Moved suspend/resume _gnttab to arch specific files
---
arch/x86/mm.c| 34 ++
gnttab.c | 10 ++
include/gnttab.h | 4
kernel.c | 4
4 files changed, 52 insertions(+)
d
Currently the watch path is not saved in the watch struct when it is registered.
During xenbus resume the path is needed so that the watches can be registered
again.
Thus, 'path' field is added to struct watch so that watches can be re-registered
during xenbus resume.
Signed-off-by: Bruno Alvisio
Before suspending the domain the shared_info_page is unmapped and for PVs the
pagetables should be canonicalized. After resume the shared_info_page should be
mapped again.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
Changed since v1:
* Fixed comment
---
arch/x86/setup.c | 51
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
events.c | 5 +
include/events.h | 1 +
kernel.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/events.c b/events.c
index e8ef8aa..342aead 100644
--- a/events.c
+++ b/events.c
@@ -183,6 +183,11 @@ void fini
Hi all,
I am sending the second revision for supporting save/restore in Mini-OS PVH.
The
branch can be found at:
https://github.com/balvisio/mini-os/tree/feature/mini-os-suspend-support-submission-2
Feedback would be greatly appreciated.
Cheers,
Bruno
Signed-off-by: Bruno Alvisio
__
The shutdown thread present in kernel.c was removed and now the thread in
shutdown.c is created instead.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
arch/x86/setup.c | 2 +-
include/kernel.h | 2 +-
kernel.c | 50 ++
3
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
kernel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel.c b/kernel.c
index 1cd40e8..782eb79 100644
--- a/kernel.c
+++ b/kernel.c
@@ -119,12 +119,12 @@ void start_kernel(void* par)
void pre_suspend(vo
Directly using the SHUTDOWN_suspend macro as a parameter for the schedop
hypercall causes an error in the Xen hypercall handler. Also for consistency,
the SHUTDOWN_suspend param is wrapped in the sched_shutdown struct.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
include/x86/x8
Currently the setup of the IDT and the request to set the HVM vector callbacks
are performed both in the trap_init function.
As part of the post-suspend operation, the HVM vector callback needs to be setup
again while the IDT does not. Thus, the trap_init function is split into two
separate functi
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
console/console.c | 15 -
console/xenbus.c | 3 +-
console/xencons_ring.c | 83 +++---
include/console.h | 6 +++-
kernel.c | 4 +++
lib/sys.c
This function is necessary as part of the pre-suspend operation.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
Changed since v1:
* Changed HYPERVISOR_shared_info for shared_info
---
arch/x86/setup.c | 12
hypervisor.c | 12
include/hypervis
For PV guests the pagetables reference the real MFNs rather than PFNs, so when
the guest is resumed into a different area of a hosts memory, these will need to
be rewritten. Thus for PV guests the MFNs need to be replaced with PFNs:
canonicalization.
PVH guests are auto-translated so no memory ope
This function is necessary as part of the pre-suspend operation.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
Changed since v1:
* Changed HYPERVISOR_shared_info for shared_info
---
arch/x86/setup.c | 12
hypervisor.c | 12
include/hypervis
xenbus_release_wait_for_watch generates a fake event to trigger make
xenbus_wait_for_watch return. This is necessary to wake up waiting threads.
release_xenbus_id additionally checks if the number of requests == 0 to wake
up the 'waiting' suspend xenbus thread.
Signed-off-by: Bruno Alvisio
Revie
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
console/console.c | 15 -
console/xenbus.c | 3 +-
console/xencons_ring.c | 83 +++---
include/console.h | 6 +++-
kernel.c | 4 +++
lib/sys.c
For PV guests the pagetables reference the real MFNs rather than PFNs, so when
the guest is resumed into a different area of a hosts memory, these will need to
be rewritten. Thus for PV guests the MFNs need to be replaced with PFNs:
canonicalization.
PVH guests are auto-translated so no memory ope
xenbus_release_wait_for_watch generates a fake event to trigger make
xenbus_wait_for_watch return. This is necessary to wake up waiting threads.
release_xenbus_id additionally checks if the number of requests == 0 to wake
up the 'waiting' suspend xenbus thread.
Signed-off-by: Bruno Alvisio
Revie
flight 119124 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 119098
Tests which
Directly using the SHUTDOWN_suspend macro as a parameter for the schedop
hypercall causes an error in the Xen hypercall handler. Also for consistency,
the SHUTDOWN_suspend param is wrapped in the sched_shutdown struct.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
include/x86/x8
Hi all,
I am sending the second revision for supporting save/restore in Mini-OS PVH.
The
branch can be found at:
https://github.com/balvisio/mini-os/tree/feature/mini-os-suspend-support-submission-2
Feedback would be greatly appreciated.
Cheers,
Bruno
Signed-off-by: Bruno Alvisio
___
Signed-off-by: Bruno Alvisio
---
Changed since v1:
* Removed resume/suspend_time() and used init/fini_time() instead
---
arch/x86/time.c | 1 -
kernel.c| 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/time.c b/arch/x86/time.c
index 3658142..8077c80 10064
The shutdown thread present in kernel.c was removed and now the thread in
shutdown.c is created instead.
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
arch/x86/setup.c | 2 +-
include/kernel.h | 2 +-
kernel.c | 50 ++
3
Created shutdown.c for the shutdown thread and all the shutdown related
functions.
Signed-off-by: Bruno Alvisio
---
Changesd since v1:
* Updated license to a BSD 3-clause. This license was taken
from the updated original file. (Repo: sysml/mini-os)
---
Makefile | 1 +
include/shut
For mini-OS to support suspend and restore, the kernel will have to suspend
different modules such as xenbus, console, irq, etc. During save/restore the
kernel and arch pre_suspend and post_suspend functions will be invoked to
suspend/resume each of the modules.
Signed-off-by: Bruno Alvisio
Revie
Signed-off-by: Bruno Alvisio
Reviewed-by: Samuel Thibault
---
kernel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel.c b/kernel.c
index 1cd40e8..782eb79 100644
--- a/kernel.c
+++ b/kernel.c
@@ -119,12 +119,12 @@ void start_kernel(void* par)
void pre_suspend(vo
Currently the setup of the IDT and the request to set the HVM vector callbacks
are performed both in the trap_init function.
As part of the post-suspend operation, the HVM vector callback needs to be setup
again while the IDT does not. Thus, the trap_init function is split into two
separate functi
New method based on polling for a importing VM to know about a new
hyper_DMABUF exported to it.
For this, the userspace now can poll the device node to check if
there a new event, which is created if there's a new hyper_DMABUF
available in importing VM (just exported).
A poll function call was ad
Upload of intial version of core framework in hyper_DMABUF driver
enabling DMA_BUF exchange between two different VMs in virtualized
platform based on Hypervisor such as XEN.
Hyper_DMABUF drv's primary role is to import a DMA_BUF from originator
then re-export it to another Linux VM so that it can
Reference document for hyper_DMABUF driver
Documentation/hyper-dmabuf-sharing.txt
Signed-off-by: Dongwon Kim
---
Documentation/hyper-dmabuf-sharing.txt | 734 +
1 file changed, 734 insertions(+)
create mode 100644 Documentation/hyper-dmabuf-sharing.txt
diff --g
From: "Matuesz Polrola"
The default backend for XEN hypervisor. This backend contains actual
implementation of individual methods defined in "struct hyper_dmabuf_bknd_ops"
defined as:
struct hyper_dmabuf_bknd_ops {
/* backend initialization routine (optional) */
int (*init)(void)
Use threaded interrupt intead of regular one because most part of ISR
is time-critical and possibly sleeps
Signed-off-by: Dongwon Kim
---
.../hyper_dmabuf/backends/xen/hyper_dmabuf_xen_comm.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf
Add a new ioctl, "IOCTL_HYPER_DMABUF_QUERY" for the userspace to
retreive various information about hyper_DMABUF, currently being shared
across VMs.
Supported query items are as followed:
enum hyper_dmabuf_query {
HYPER_DMABUF_QUERY_TYPE = 0x10,
HYPER_DMABUF_QUERY_EXPORTER,
Define a private data (e.g. meta data for the buffer) attached to
each hyper_DMABUF structure. This data is provided by userapace via
export_remote IOCTL and its size can be up to 192 bytes.
Signed-off-by: Dongwon Kim
Signed-off-by: Mateusz Polrola
---
drivers/dma-buf/hyper_dmabuf/hyper_dmabuf_
All of hyper_DMABUF operations now (hyper_dmabuf_ops.c) send a message
to the exporting VM for synchronization between two VMs. For this, every
mapping done by importer will make exporter perform shadow mapping of
original DMA-BUF. Then all consecutive DMA-BUF operations (attach, detach,
map/unmap
This patch series contains the implementation of a new device driver,
hyper_DMABUF driver, which provides a way to expand the boundary of
Linux DMA-BUF sharing to across different VM instances in Multi-OS platform
enabled by a Hypervisor (e.g. XEN)
This version 2 series is basically refactored ver
Hyper_DMABUF DRIVER
M: Dongwon Kim
M: Mateusz Polrola
L: linux-ker...@vger.kernel.org
L: xen-devel@lists.xenproject.org
S: Maintained
F: drivers/dma-buf/hyper_dmabuf*
F: include/uapi/linux/hyper_dmabuf.h
F: Documentation/hyper-dmabuf-sharing.txt
T: htt
Hi all:
I am using arm64 ( hikey) to test for xen.
After struggling for two week, I was able to build and install everything
on the target, xen and dom0 kernel boots up ok.
However, when I try to use “xl list”, it hangs, I realized I have to start
the xencommons service first. But
flight 119114 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 119098
Tests which
flight 119108 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 119098
Tests which
flight 119064 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119064/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
On Tue, 13 Feb 2018, Julien Grall wrote:
> On 02/09/2018 07:12 PM, Julien Grall wrote:
> > Hi,
> >
> > On 02/09/2018 07:10 PM, Stefano Stabellini wrote:
> > > On Fri, 9 Feb 2018, Julien Grall wrote:
> > > > On 02/09/2018 07:02 PM, Stefano Stabellini wrote:
> > > > > On Fri, 9 Feb 2018, Julien Gral
... so that it is clear it is PV only and can be moved later.
No functional change intended.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 14 ++
xen/include/asm-x86/pv/mm.h | 7 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm.c b/
This is in preparation for adding an extra parameter to
get_page_from_l1e for disallow mask.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c| 19 +--
xen/arch/x86/pv/mm.h | 19 +++
2 files changed, 20 insertions(+), 18 deletions(-)
diff --
This will make moving pv mm code easier. To retain same behaviour the
base mask is copied to shadow code.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 13 +++--
xen/arch/x86/mm/shadow/multi.c | 15 ---
xen/arch/x86/pv/ro-page-fault.c |
The two functions are only used by PV code paths because:
1. To allocate a PGT_l*_page_table type page, a DomU must explicitly
request such types via PV MMU hypercall.
2. PV Dom0 builder explicitly asks for PGT_l*_page_table type pages,
but it is obviously PV only.
3. p2m_alloc_ptp explicitl
The function will skip stamping the page when the page is used as page
table in shadow mode. Since it is called both in PV code and common
code we need to export it.
Signed-off-by: Wei Liu
---
I tried to move it to a header to keep in static inline but couldn't
find a place that works.
This func
Linear page table is a PV only feature. The functions used to handle
that will be moved.
Create a function for decreasing linear page table count. It is called
unconditionally from common code so the stub is empty.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c |
And replace open-coded _put_page_type where the parent table parameter
is not null.
This is in preparation for code movement in which various
put_page_from_lNe will be moved to pv/mm.c.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c| 28 ++--
xen/include/asm-x86/mm
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 0b5fd199a4..97d2ea17fb 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -128,8 +128,6 @@
#include
#include
-#include "pv/mm.h"
-
/* Overrid
Hello
This series can be found at:
https://xenbits.xen.org/git-http/people/liuw/xen.git wip.split-mm-v6.1
Unfortunately there isn't any resemblance to v5 because a lot of things
have changed since Sept last year. And the opinions gathered at the time
would make this version more or less a comp
The current XPTI implementation isolates the directmap (and therefore a lot of
guest data), but a large quantity of CPU0's state (including its stack)
remains visible.
Furthermore, an attacker able to read .text is in a vastly superior position
to normal when it comes to fingerprinting Xen for kno
On 02/09/2018 07:12 PM, Julien Grall wrote:
Hi,
On 02/09/2018 07:10 PM, Stefano Stabellini wrote:
On Fri, 9 Feb 2018, Julien Grall wrote:
On 02/09/2018 07:02 PM, Stefano Stabellini wrote:
On Fri, 9 Feb 2018, Julien Grall wrote:
Hi,
On 02/08/2018 11:49 PM, Stefano Stabellini wrote:
On Thu
flight 119098 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119098/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Feb 7, 2018, at 11:05, Jan Beulich wrote:
>
> 1: slightly reduce Meltdown band-aid overhead
> 2: remove CR reads from exit-to-guest path
> 3: introduce altinstruction_nop assembler macro
> 4: NOP out most XPTI entry/exit code when it's not in use
> 5: avoid double CR3 reload when switching to
Pardon any weird formatting, I'm replying on my phone.
Because they are two different things. One is an assert to make sure nothing
wrong is happening with the EFER.SVME bit, and the other changes what features
are enabled.
IIRC, most asserts are on their on ifs and not in a if statement wi
Hi,
On 13/02/18 16:52, Julien Grall wrote:
> Hi Andre,7
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Add an MMIO handling framework to the VGIC emulation:
>> Each register is described by its offset, size (or number of bits per
>> IRQ, if applicable) and the read/write handler functions. We pr
On 13/02/18 17:11, Jan Beulich wrote:
> Along the lines of commit 7226486767 ("x86/srat: fix the end pfn check
> in valid_numa_range()") nodes_cover_memory() also doesn't consistently
> use "end": It's set to an inclusive value initially, but then compared
> to the exclusive "end" field of struct n
Along the lines of commit 7226486767 ("x86/srat: fix the end pfn check
in valid_numa_range()") nodes_cover_memory() also doesn't consistently
use "end": It's set to an inclusive value initially, but then compared
to the exclusive "end" field of struct node and also possibly set to
nodes[j].start, m
>>> On 13.02.18 at 17:28, wrote:
> On Tue, Feb 13, 2018 at 09:16:19AM -0700, Jan Beulich wrote:
>> >>> On 13.02.18 at 16:53, wrote:
>> > On Wed, Jan 24, 2018 at 10:01:18AM +, Roger Pau Monne wrote:
>> >> Hello,
>> >>
>> >> The following patch series enables LLVM coverage support for the Xen
Hi Andre,7
On 09/02/18 14:39, Andre Przywara wrote:
Add an MMIO handling framework to the VGIC emulation:
Each register is described by its offset, size (or number of bits per
IRQ, if applicable) and the read/write handler functions. We provide
initialization macros to describe each GIC register
On Tue, Feb 13, 2018 at 09:16:19AM -0700, Jan Beulich wrote:
> >>> On 13.02.18 at 16:53, wrote:
> > On Wed, Jan 24, 2018 at 10:01:18AM +, Roger Pau Monne wrote:
> >> Hello,
> >>
> >> The following patch series enables LLVM coverage support for the Xen
> >> hypervisor. A sample coverage report
On 13/02/18 15:48, Roger Pau Monné wrote:
> On Tue, Feb 13, 2018 at 08:22:33AM -0700, Jan Beulich wrote:
> On 13.02.18 at 16:11, wrote:
>>> On Tue, Feb 13, 2018 at 06:41:14AM -0700, Jan Beulich wrote:
>>> On 13.02.18 at 12:27, wrote:
> On Tue, Feb 13, 2018 at 04:04:17AM -0700, Jan Beu
On 13/02/18 16:35, Julien Grall wrote:
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable.
I forgot to mention one thing. This is not the main usage of this
function
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable.
This is based on Linux commit 90eee56c5f90, written by Eric Auger.
Signed-off-by: Andre Przywara
---
xen/arch/arm/v
On Tue, Feb 13, 2018 at 3:56 PM, Andre Przywara
wrote:
> Hi,
>
> Christoffer, Eric, Marc,
> a question about locking order between multiple IRQs below. Could you
> have a brief look, please?
>
> On 13/02/18 12:30, Julien Grall wrote:
>> Hi Andre,
>>
>> On 09/02/18 14:39, Andre Przywara wrote:
>>>
>>> On 13.02.18 at 16:53, wrote:
> On Wed, Jan 24, 2018 at 10:01:18AM +, Roger Pau Monne wrote:
>> Hello,
>>
>> The following patch series enables LLVM coverage support for the Xen
>> hypervisor. A sample coverage report obtained after booting a PVHv2 Dom0
>> can be found at:
>>
>> http://xe
On Wed, Jan 24, 2018 at 10:01:18AM +, Roger Pau Monne wrote:
> Hello,
>
> The following patch series enables LLVM coverage support for the Xen
> hypervisor. A sample coverage report obtained after booting a PVHv2 Dom0
> can be found at:
>
> http://xenbits.xen.org/people/royger/xen_profile/
>
On Tue, Feb 13, 2018 at 08:22:33AM -0700, Jan Beulich wrote:
> >>> On 13.02.18 at 16:11, wrote:
> > On Tue, Feb 13, 2018 at 06:41:14AM -0700, Jan Beulich wrote:
> >> >>> On 13.02.18 at 12:27, wrote:
> >> > On Tue, Feb 13, 2018 at 04:04:17AM -0700, Jan Beulich wrote:
> >> >> >>> On 13.02.18 at 10:
On Tue, Feb 13, 2018 at 06:40:20AM -0700, Jan Beulich wrote:
> >>> On 13.02.18 at 12:13, wrote:
> > On Tue, Feb 13, 2018 at 04:05:45AM -0700, Jan Beulich wrote:
> >> >>> On 13.02.18 at 11:29, wrote:
> >> > On Tue, Feb 13, 2018 at 03:06:24AM -0700, Jan Beulich wrote:
> >> >> >>> On 12.02.18 at 11:
Hi,
On 13/02/18 12:41, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Implement the framework for syncing IRQs between our emulation and the
>> list registers, which represent the guest's view of IRQs.
>> This is done in kvm_vgic_flush_hwstate and kvm_vgic_sync_hw
>>> On 13.02.18 at 15:41, wrote:
> On 13/02/18 14:22, Jan Beulich wrote:
> On 12.02.18 at 12:23, wrote:
>>> @@ -118,26 +113,6 @@ extern void alternative_instructions(void);
>>>newinstr2, feature2) \
>>> : output : input)
>>>
>
flight 119079 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119079/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 13.02.18 at 16:15, wrote:
> I've updated the comments according to your previous suggestions,
> do they look good to you?
The one in the public header is way too verbose. I specifically don't
see why you would need to spell out XSM privilege requirements
there. Please make new comments mat
>>> On 13.02.18 at 16:11, wrote:
> On Tue, Feb 13, 2018 at 06:41:14AM -0700, Jan Beulich wrote:
>> >>> On 13.02.18 at 12:27, wrote:
>> > On Tue, Feb 13, 2018 at 04:04:17AM -0700, Jan Beulich wrote:
>> >> >>> On 13.02.18 at 10:59, wrote:
>> >> > On Tue, Feb 13, 2018 at 02:29:08AM -0700, Jan Beuli
On Tue, Feb 13, 2018 at 06:41:14AM -0700, Jan Beulich wrote:
> >>> On 13.02.18 at 12:27, wrote:
> > On Tue, Feb 13, 2018 at 04:04:17AM -0700, Jan Beulich wrote:
> >> >>> On 13.02.18 at 10:59, wrote:
> >> > On Tue, Feb 13, 2018 at 02:29:08AM -0700, Jan Beulich wrote:
> >> >> >>> On 08.02.18 at 13:
Hi Jan,
I've updated the comments according to your previous suggestions,
do they look good to you?
2018-02-01 18:23 GMT+08:00 Jan Beulich :
On 30.01.18 at 18:50, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4126,6 +4126,10 @@ int xenmem_add_to_physmap_one(
>>
Hi,
On 13/02/18 12:02, Julien Grall wrote:
> On 12/02/18 17:53, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 12/02/18 13:55, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
On 13/02/18 14:56, Andre Przywara wrote:
Hi,
On 13/02/18 14:31, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
+/* Requires the VCPU's ap_list_lock to be held. */
+static void vgic_flush_lr_state(struct vcpu *vcpu)
+{
+ struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic
On 13/02/18 14:56, Andre Przywara wrote:
diff --git a/xen/common/list_sort.c b/xen/common/list_sort.c
new file mode 100644
index 00..9c5cc58e43
--- /dev/null
+++ b/xen/common/list_sort.c
@@ -0,0 +1,170 @@
+/*
+ * list_sort.c: merge sort implementation for linked lists
+ * Copied from th
Hi,
On 13/02/18 14:31, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> +/* Requires the VCPU's ap_list_lock to be held. */
>> +static void vgic_flush_lr_state(struct vcpu *vcpu)
>> +{
>> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
>> + struct vgic_irq
Hi,
Christoffer, Eric, Marc,
a question about locking order between multiple IRQs below. Could you
have a brief look, please?
On 13/02/18 12:30, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Adds the sorting function to cover the case where you have more IRQs
>>
flight 119060 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119060/
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 13/02/18 14:22, Jan Beulich wrote:
On 12.02.18 at 12:23, wrote:
>> --- a/xen/include/asm-x86/alternative.h
>> +++ b/xen/include/asm-x86/alternative.h
>> @@ -65,11 +65,6 @@ extern void alternative_instructions(void);
>> ALTERNATIVE(oldinstr, newinstr1, feature1)
>>> On 12.02.18 at 12:23, wrote:
> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -9,60 +9,67 @@
> * enough information for the alternatives patching code to patch an
> * instruction. See apply_alternatives().
> */
> -.macro altinstruction_ent
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
+/* Requires the VCPU's ap_list_lock to be held. */
+static void vgic_flush_lr_state(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
+struct vgic_irq *irq;
+int count = 0;
+
+ASSERT(spin_is_locked(&vgic_c
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC regist
On 13/02/18 15:16, Jan Beulich wrote:
On 13.02.18 at 12:36, wrote:
>> On 12/02/18 18:54, Dario Faggioli wrote:
>>> On Fri, 2018-02-09 at 15:01 +0100, Juergen Gross wrote:
This series is available via github:
https://github.com/jgross1/xen.git xpti
Dario wants to do so
>>> On 12.02.18 at 12:23, wrote:
> * Rename some fields for consistency and clarity, and use standard types.
> * Don't opencode the use of ALT_{ORIG,REPL}_PTR().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
1 - 100 of 155 matches
Mail list logo
