On 03/07/17 23:08, Stefano Stabellini wrote:
> When the other end notifies us that there are commands to be read
> (pvcalls_back_event), wake up the backend thread to parse the command.
>
> The command ring works like most other Xen rings, so use the usual
> ring macros to read and write to it. Th
>>> On 04.07.17 at 05:05, wrote:
> On 07/03/17 09:42 -0600, Jan Beulich wrote:
>> >>> On 03.07.17 at 05:46, wrote:
> [..]
>> > void mctelem_process_deferred(unsigned int cpu,
>> > -int (*fn)(mctelem_cookie_t))
>> > +int (*fn)(mctelem_cookie_t),
>>
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2017年7月4日 7:00
> To: Wei Chen
> Cc: xen-devel@lists.xen.org; sstabell...@kernel.org; Steve Capper
> ; Kaly Xin ; Julien Grall
> ; nd
> Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: SMMU: S
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2017年7月4日 6:30
> To: Wei Chen
> Cc: xen-devel@lists.xen.org; sstabell...@kernel.org; Steve Capper
> ; Kaly Xin ; Julien Grall
> ; nd
> Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: SMMU: D
flight 111370 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111370/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1e6add9e476696461526163bde843570cfdffb39
baseline version:
ovmf fb5a64de3a8be8482c317
Hi, Owen!
On 07/03/2017 03:57 PM, Owen Smith wrote:
determine the difference between older
backends and newer backends. In the case I'm interested in, the difference
between old QEMU vkbd backend which blocks waiting for the vfb device, which
is not present on HVM guests, and a newer QEMU backen
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2017年7月4日 6:03
> To: Wei Chen
> Cc: xen-devel@lists.xen.org; sstabell...@kernel.org; Steve Capper
> ; Kaly Xin ; Julien Grall
> ; nd
> Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: SMMU: I
On 03/07/17 20:44, Igor Druzhinin wrote:
> On 03/07/17 16:40, Juergen Gross wrote:
>> When setting up the Xenstore watch for the memory target size the new
>> watch will fire at once. Don't try to reach the configured target size
>> by onlining new memory in this case, as the current memory size wi
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2017年7月4日 5:58
> To: Wei Chen
> Cc: xen-devel@lists.xen.org; sstabell...@kernel.org; Steve Capper
> ; Kaly Xin ; Julien Grall
> ; nd
> Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: SMMU: I
flight 111359 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111359/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in
111265
test-amd64-amd64-xl-qemuu-wi
This run is configured for baseline tests only.
flight 71630 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71630/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-localmigrate fail R
On Thu, Jun 29, 2017 at 01:49:52AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> According to SDM 10.11.1, only [19:12] bits of MSI address are
> Destination ID, change the mask to avoid ambiguity for VT-d spec
> has used the bit 4 to indicate a remappable interrupt request.
>
> Signed-off-by: C
flight 111369 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111369/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fb5a64de3a8be8482c3173f85cddda5ae204fe40
baseline version:
ovmf 7b1dc6c569a88ab85af5f
flight 111357 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-saverestorefail REGR. vs. 111280
test-amd64-amd64-xl-
On 07/03/17 09:42 -0600, Jan Beulich wrote:
> >>> On 03.07.17 at 05:46, wrote:
[..]
> > void mctelem_process_deferred(unsigned int cpu,
> > - int (*fn)(mctelem_cookie_t))
> > + int (*fn)(mctelem_cookie_t),
> > + bool lmce)
>
Hi Anthony:
On 2017年06月30日 23:48, Anthony PERARD wrote:
> On Thu, Jun 29, 2017 at 01:49:53AM -0400, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
>> format. The original code isn't suitable to the new format. A new pair
>> bin
Hi Wei:
Thanks for your review.
On 2017年06月30日 21:05, Wei Liu wrote:
> On Thu, Jun 29, 2017 at 01:50:33AM -0400, Lan Tianyu wrote:
> [...]
>> > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> > index dc8e876..8ba4f5a 100644
>> > --- a/xen/common/Kconfig
>> > +++ b/xen/common/Kcon
On 17-06-30 03:18:53, Jan Beulich wrote:
> >>> Yi Sun 06/30/17 10:05 AM >>>
> >On 17-06-30 01:33:02, Jan Beulich wrote:
> >> >>> Yi Sun 06/30/17 9:01 AM >>>
> >> >This accords to spec:
> >> >"For CDP operations, COS_MAX_CDP is equal to (CPUID.(EAX=10H,
> >> >ECX=1):EDX.COS_MAX_CAT >>1)."
> >> >
This run is configured for baseline tests only.
flight 71629 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71629/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-libvirt5 libvirt-buildfai
On Mon, 3 Jul 2017, Owen Smith wrote:
> Backends set "feature-raw-pointer" if its capable of reporting
> absolute positions without scaling the coordinates to screen
> size. This should be set during the backend init.
> Frontends set "request-raw-pointer" to request that backends
> do not rescale a
flight 111367 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111367/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7b1dc6c569a88ab85af5f7462aa63ea1f898276a
baseline version:
ovmf 94f5c6001c41a2d4e3d59
On Fri, 30 Jun 2017, Wei Chen wrote:
> The SMMU MasterIDs are placed at the master devices' DT node while
> using the generic bindings. In this case, it's very hard for us to
> register SMMU masters while probing SMMU as we had done for legacy
> bindings. Because we have to go through whole device
flight 111352 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111352/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 4 host-install broken pass in 111308
test-armhf-armhf-xl-xsm 5 host-p
On Fri, 30 Jun 2017, Wei Chen wrote:
> The legacy IOMMU bindings place the SMMU MasterIDs in the SMMU device
> tree node. In current code, we register the SMMU masters while probing
> SMMU. It's better to keep registering legacy masters in the SMMU probing
> progress. If we move registering legacy
On Fri, 30 Jun 2017, Wei Chen wrote:
> The device tree provides two types of IOMMU bindings, one is legacy
> another is generic. The legacy bindings will be depercated in favour
^ deprecated
> of the generic bindings. But in the transitional period
On Fri, 30 Jun 2017, Wei Chen wrote:
> In previous code, while we are constructing Dom0, we will assign
> all devices except passthrough devices to Dom0. In the later, when
> we start the DomU, the assign_device will prepare SMMU resources
> for the devices passthrough to DomU. This is ok when we k
On Fri, 30 Jun 2017, Wei Chen wrote:
> In current code, we only have the iommu_add_device to add PCI device
> to IOMMU. But for ARM SMMU, we don't have a separate helper to add
> platform device with device tree to SMMU. This work was included in
> the iommu_assign_dt_device. But sometimes, we just
On Fri, 30 Jun 2017, Wei Chen wrote:
> This add_device callback function is taking care of adding a device
> to SMMU and make sure it is fully prepare to be used by the SMMU
> afterwards.
>
> In previous code, we don't implement the add_device callback in
> iommu_ops for ARM SMMU. We placed the wo
On Fri, 30 Jun 2017, Wei Chen wrote:
> It's a error message about XEN_DOMCTL_deassign_device, but the
> print message is XEN_DOMCTL_assign_device.
>
> Signed-off-by: Wei Chen
Reviewed-by: Stefano Stabellini
> ---
> xen/drivers/passthrough/device_tree.c | 4 ++--
> 1 file changed, 2 insertion
This run is configured for baseline tests only.
flight 71628 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71628/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-libvirt5 libvirt-buildfai
On Mon, 3 Jul 2017, Igor Druzhinin wrote:
> On 01/07/17 01:06, Stefano Stabellini wrote:
> > On Fri, 30 Jun 2017, Igor Druzhinin wrote:
> >> Dummys are simple anonymous mappings that are placed instead
> >> of regular foreign mappings in certain situations when we need
> >> to postpone the actual m
Introduce the code to handle xenbus state changes.
Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.
Introduce stub functions for disconnecting/connecting to a frontend.
Signed-off
Allocate a socket. Track the allocated passive sockets with a new data
structure named sockpass_mapping. It contains an unbound workqueue to
schedule delayed work for the accept and poll commands. It also has a
reqcopy field to be used to store a copy of a request for delayed work.
Reads/writes to
Introduce a xenbus backend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.
When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.
The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs f
Implement backend_disconnect. Call pvcalls_back_release_active on active
sockets and pvcalls_back_release_passive on passive sockets.
Implement module_exit by calling backend_disconnect on frontend
connections.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
When an active socket has data available, increment the io and read
counters, and schedule the ioworker.
Implement the read function by reading from the socket, writing the data
to the data ring.
Set in_error on error.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@
Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Allocate a workqueue and a work_struct, called ioworker, to perform
reads and write
Implement poll on passive sockets by requesting a delayed response with
mappass->reqcopy, and reply back when there is data on the passive
socket.
Poll on active socket is unimplemented as by the spec, as the frontend
should just wait for events and check the indexes on the indexes page.
Only sup
Introduce a per-frontend data structure named pvcalls_fedata. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, accept and poll commands, while active
sockets only on relea
Introduce the C header file which defines the PV Calls interface. It is
imported from xen/include/public/io/pvcalls.h.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/pvcall
Keep a list of connected frontends. Use a semaphore to protect list
accesses.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 22 ++
1 file changed, 22 insertions(+)
diff --gi
Release both active and passive sockets. For active sockets, make sure
to avoid possible conflicts with the ioworker reading/writing to those
sockets concurrently. Set map->release to let the ioworker know
atomically that the socket will be released soon, then wait until the
ioworker finishes (flus
We have one ioworker per socket. Each ioworker goes through the list of
outstanding read/write requests. Once all requests have been dealt with,
it returns.
We use one atomic counter per socket for "read" operations and one
for "write" operations to keep track of the reads/writes to do.
We also u
Also add pvcalls-back to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 12
drivers/xen/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f15
Call inet_listen to implement the listen command.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/xen/pvcalls-back.
When the other end notifies us that there is data to be written
(pvcalls_back_conn_event), increment the io and write counters, and
schedule the ioworker.
Implement the write function called by ioworker by reading the data from
the data ring, writing it to the socket by calling inet_sendmsg.
Set
Implement the accept command by calling inet_accept. To avoid blocking
in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
scheduled on sk_data_ready (for a passive socket, it means that there
are connections to accept).
Use the reqcopy field to store the request. Accept the ne
Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 27 +++
Hi all,
this series introduces the backend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them an
On Mon, 3 Jul 2017, Juergen Gross wrote:
> On 22/06/17 21:14, Stefano Stabellini wrote:
> > When the other end notifies us that there are commands to be read
> > (pvcalls_back_event), wake up the backend thread to parse the command.
> >
> > The command ring works like most other Xen rings, so use
On 01/07/17 01:08, Stefano Stabellini wrote:
> On Fri, 30 Jun 2017, Igor Druzhinin wrote:
>> This new call is trying to update a requested map cache entry
>> according to the changes in the physmap. The call is searching
>> for the entry, unmaps it, tries to translate the address and
>> maps again
On 01/07/17 01:06, Stefano Stabellini wrote:
> On Fri, 30 Jun 2017, Igor Druzhinin wrote:
>> Dummys are simple anonymous mappings that are placed instead
>> of regular foreign mappings in certain situations when we need
>> to postpone the actual mapping but still have to give a
>> memory region to
From: Michel Lespinasse
Add __rb_change_child() as an inline helper function to replace code that
would otherwise be duplicated 4 times in the source.
No changes to binary size or speed.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: D
From: Michel Lespinasse
In rb_erase, move the easy case (node to erase has no more than
1 child) first. I feel the code reads easier that way.
Signed-off-by: Michel Lespinasse
Reviewed-by: Rik van Riel
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: David Woodhouse
Signed-off-by: Andrew Morton
From: Michel Lespinasse
An interesting observation for rb_erase() is that when a node has
exactly one child, the node must be black and the child must be red.
An interesting consequence is that removing such a node can be done by
simply replacing it with its child and making the child black,
whic
From: Wei Yang
In case 1, it passes down the BLACK color from G to p and u, and maintains
the color of n. By doing so, it maintains the black height of the sub-tree.
While in the comment, it marks the color of n to BLACK. This is a typo
and not consistents with the code.
This patch fixs this
From: Michel Lespinasse
Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
and color information (possibly not in close sequence, as there might
be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the
From: Michel Lespinasse
Set comment and indentation style to be consistent with linux coding style
and the rest of the file, as suggested by Peter Zijlstra
Signed-off-by: Michel Lespinasse
Cc: Andrea Arcangeli
Acked-by: David Woodhouse
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Daniel Santos
From: Michel Lespinasse
When looking to fetch a node's sibling, we went through a sequence of:
- check if node is the parent's left child
- if it is, then fetch the parent's right child
This can be replaced with:
- fetch the parent's right child as an assumed sibling
- check that node is NOT the
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, depending on the color of the 'other' child
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()
functions.
Also when the current node is red or when
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 a loop exit, at which point the root would be
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 case.
- Flipping gparent's color to red requires
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 more. However at that point the node's parent
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 other cases (exiting after tree rotations, or
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
{
...
}
guar
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
Cc: Andrea Arcangeli
Acked-by: David Woodhouse
The patch inlines the rbtree related files to Linux coding conventions to have
limited conflicts in future while porting from Linux tree.
Signed-off-by: Praveen Kumar
---
New in v4.
---
xen/common/rbtree.c | 630 +++
xen/include/xen/rbtree.h | 39
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 88d19cf37952 ("timers: Add rb_init_node() to allo
Hi All,
The patch imports the changes and updates of the rbtree implementaiton
from Linux tree. But since, the only current implementation is with tmem.c,
which am not much aware off much and therefore, was unable to test the changes
thoroughly. Having said that, I do have plans of adding futher c
flight 111361 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111361/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 94f5c6001c41a2d4e3d5953e4300337d6ebe
baseline version:
ovmf cf6da5569307cb3033465
I was able to cross-compile the hypervisor on an amd64 host for the aarch64
target. However, I can't build the Xen toolset.
I am following the "Xen ARM with Virtualization Extensions/CrossCompiling"
page, "Build arm64 tools" section. When I execute:
"./configure --build=x86_64-unknown-linux-gnu
There are many references to the "Xen Tools", but I can't find any
documentation that explains what the "Xen Tools" are.
What is provided with the Xen Tools and why do I need them?
Regards, Nick Garnett
Zazzu Firmware Architect
___
Xen-devel mailin
On 03/07/17 16:40, Juergen Gross wrote:
> When setting up the Xenstore watch for the memory target size the new
> watch will fire at once. Don't try to reach the configured target size
> by onlining new memory in this case, as the current memory size will
> be smaller in almost all cases due to e.g
On Mon, Jul 3, 2017 at 10:58 AM, Andrii Anisov wrote:
> Hello Meng Xu,
>
>
> On 03.07.17 16:35, Meng Xu wrote:
>>>
>>> Do you have any recommendations or suggestions?
>>
>> Which experiment/use case do you plan to run?
>> What are the requirements (or performance guarantees) you want to have
>> fr
Hi Haoran,
On Mon, Jul 3, 2017 at 12:17 PM, Haoran Li wrote:
>
> From: naroahlee
>
> When more than one idle VCPUs that have
> the same PCPU as their previous running core invoke runq_tickle(), they will
> tickle the same PCPU. The tickled PCPU will only pick at most one VCPU, i.e.,
> the hi
On Mon, 3 Jul 2017, Zhongze Liu wrote:
> Hi Jan,
>
> 2017-07-03 22:25 GMT+08:00 Jan Beulich :
> On 30.06.17 at 22:15, wrote:
> >> /*
> >> * Set access permissions, cacheability and shareability (ARM only) of a
> >> * continuos range of normal memory (RAM) in the stage-2 page table.
> >> *
flight 111364 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111364/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
This run is configured for baseline tests only.
flight 71627 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71627/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-libvirt5 libvirt-buildfai
flight 111344 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255
REGR. vs. 110441
Tes
On Mon, 3 Jul 2017, Zhongze Liu wrote:
> Hi Julien,
>
> 2017-07-03 19:16 GMT+08:00 Julien Grall :
> > Hi,
> >
> > On 01/07/17 10:16, Zhongze Liu wrote:
> >>>
> >>> On the ARM side, we are missing BUFFERABLE and WRITEALLOC. I don't know
> >>> how they map to these tags, which comes from the x86 wor
On Sun, 2 Jul 2017, Julien Grall wrote:
> Hi,
>
> On 06/30/2017 10:19 PM, Stefano Stabellini wrote:
> > On Thu, 22 Jun 2017, Volodymyr Babchuk wrote:
> > > PSCI handling code had helper routine that checked calling convention.
> > > It does not needed anymore, because:
> > >
> > > - Generic han
On 03/07/17 17:06, Jan Beulich wrote:
On 03.07.17 at 17:07, wrote:
>> On 22/06/17 10:06, Jan Beulich wrote:
+{
+ASSERT_UNREACHABLE();
+goto unhandleable;
+}
+
+do {
+enum hvm_translation_result res;
+struct pa
On Mon, 2017-07-03 at 11:17 -0500, Haoran Li wrote:
> From: naroahlee
>
> When more than one idle VCPUs that have
> the same PCPU as their previous running core invoke runq_tickle(),
> they will
> tickle the same PCPU. The tickled PCPU will only pick at most one
> VCPU, i.e.,
> the highest-pr
This run is configured for baseline tests only.
flight 71626 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71626/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-43 host-install(3)
We have to fix some old data. We insist that the old data is indeed
old (more than 5 years old) and not part of proper flights (ie,
blessed "play" or "crashed" or "unknown").
Signed-off-by: Ian Jackson
---
schema/testid-constraint.sql | 28
1 file changed, 28 insert
The test database should be just like the real one, even if the schema
compatibility looks wrong. So pass -ff to mg-schema-update.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-schema-test-database b/mg-schema-test-
This can be useful when testing things which involve old data, rather
than things which just involve new data.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mg-schema-test-database b/mg-schema-test-database
i
We make mg-schema-test-database work again. Also, we make testid be
NOT NULL. (Everything sets it and has done almost forever.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 111336 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111336/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-stop fail in 111294
pass in 111336
test-armhf-armhf-xl
On Mon, Jul 03, 2017 at 07:34:12AM +0800, Dongli Zhang wrote:
> This patch adds new interface for GNTTABOP_query_size in libxc to help
> query the current grant table frames and maximum grant table frames for a
> specific domain.
>
> Signed-off-by: Dongli Zhang
Acked-by: Wei Liu
__
On Mon, Jul 03, 2017 at 07:34:13AM +0800, Dongli Zhang wrote:
> As both xen-netfront and xen-blkfront support multi-queue, they would
> consume a lot of grant table references when there are many paravirtual
> devices and vcpus assigned to guest. Guest domU might panic or hang due to
> grant alloca
On 31/05/17 08:37, Jan Beulich wrote:
> This re-enables tests on configurations where commit 0d6968635c
> ("hvmloader: avoid tests when they would clobber used memory") forced
> them to be skipped.
>
> Signed-off-by: Jan Beulich
I still fail to see the value in retaining these tests. They only c
From: naroahlee
When more than one idle VCPUs that have
the same PCPU as their previous running core invoke runq_tickle(), they will
tickle the same PCPU. The tickled PCPU will only pick at most one VCPU, i.e.,
the highest-priority one, to execute. The other VCPUs will not be scheduled
for a
On 03/07/17 18:11, Jan Beulich wrote:
On 03.07.17 at 17:40, wrote:
>> --- a/drivers/xen/xen-balloon.c
>> +++ b/drivers/xen/xen-balloon.c
>> @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch,
>> {
>> unsigned long long new_target;
>> int err;
>> +static bool
>>> On 03.07.17 at 17:40, wrote:
> --- a/drivers/xen/xen-balloon.c
> +++ b/drivers/xen/xen-balloon.c
> @@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch,
> {
> unsigned long long new_target;
> int err;
> + static bool watch_fired;
> + static unsigned long t
>>> On 03.07.17 at 17:07, wrote:
> On 22/06/17 10:06, Jan Beulich wrote:
>>> +{
>>> +ASSERT_UNREACHABLE();
>>> +goto unhandleable;
>>> +}
>>> +
>>> +do {
>>> +enum hvm_translation_result res;
>>> +struct page_info *page;
>>> +pagefault_info_t pfi
Hi Jan,
2017-07-03 22:25 GMT+08:00 Jan Beulich :
On 30.06.17 at 22:15, wrote:
>> /*
>> * Set access permissions, cacheability and shareability (ARM only) of a
>> * continuos range of normal memory (RAM) in the stage-2 page table.
>> */
>> /* XEN_DOMCTL_memattrs_op */
>>
>> /* set chacheab
>>> On 03.07.17 at 05:46, wrote:
> @@ -454,6 +455,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
> uint64_t gstatus;
> mctelem_cookie_t mctc = NULL;
> struct mca_summary bs;
> +bool wait, lmce;
Considering the code being replaced as well as ...
> @@ -462,6 +464
1 - 100 of 189 matches
Mail list logo
