[Xen-devel] [ovmf test] 111370: all pass - PUSHED

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

Re: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

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

Re: [Xen-devel] [PATCH 2/7] xen/arm: SMMU: Introduce a helper to add DT device to SMMU

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 >

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

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

Re: [Xen-devel] [PATCH 1/7] xen/arm: SMMU: Implement the add_device callback in SMMU

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 >

[Xen-devel] [qemu-mainline test] 111359: tolerable FAIL - PUSHED

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

[Xen-devel] [ovmf baseline-only test] 71630: tolerable FAIL

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

Re: [Xen-devel] [Qemu-devel] [PATCH 1/3] i386/msi: Correct mask of destination ID in MSI address

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.

[Xen-devel] [ovmf test] 111369: all pass - PUSHED

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

[Xen-devel] [linux-next test] 111357: regressions - FAIL

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

Re: [Xen-devel] [PATCH v5 03/11] x86/mce: handle host LMCE

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), > > +

Re: [Xen-devel] [PATCH 2/3] xen-pt: bind/unbind interrupt remapping format MSI

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

Re: [Xen-devel] [PATCH 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

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 >> > +++

Re: [Xen-devel] [PATCH v12 13/23] x86: refactor psr: CDP: implement CPU init flow.

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

[Xen-devel] [ovmf baseline-only test] 71629: tolerable FAIL

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-build

Re: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

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

[Xen-devel] [ovmf test] 111367: all pass - PUSHED

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

Re: [Xen-devel] [PATCH 6/7] xen/arm: SMMU: Support generic IOMMU bindings

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

[Xen-devel] [xen-unstable test] 111352: tolerable FAIL

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

Re: [Xen-devel] [PATCH 5/7] xen/arm: SMMU: Keep registering legacy master in SMMU probe

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

Re: [Xen-devel] [PATCH 4/7] xen/arm: SMMU: Detect types of device tree binding

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

Re: [Xen-devel] [PATCH 3/7] xen/arm: Prepare SMMU resources for protected devices

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

Re: [Xen-devel] [PATCH 2/7] xen/arm: SMMU: Introduce a helper to add DT device to SMMU

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

Re: [Xen-devel] [PATCH 1/7] xen/arm: SMMU: Implement the add_device callback in SMMU

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

Re: [Xen-devel] [PATCH 7/7] xen: Fix a typo in error message of iommu_do_dt_domctl

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-devel] [ovmf baseline-only test] 71628: tolerable FAIL

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-build

Re: [Xen-devel] [PATCH 2/4] xen/mapcache: add an ability to create dummy mappings

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

[Xen-devel] [PATCH v6 04/18] xen/pvcalls: xenbus state handling

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.

[Xen-devel] [PATCH v6 09/18] xen/pvcalls: implement bind command

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

[Xen-devel] [PATCH v6 02/18] xen/pvcalls: introduce the pvcalls xenbus backend

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

[Xen-devel] [PATCH v6 06/18] xen/pvcalls: handle commands from the frontend

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

[Xen-devel] [PATCH v6 14/18] xen/pvcalls: disconnect and module_exit

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:

[Xen-devel] [PATCH v6 16/18] xen/pvcalls: implement read

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:

[Xen-devel] [PATCH v6 08/18] xen/pvcalls: implement connect command

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

[Xen-devel] [PATCH v6 12/18] xen/pvcalls: implement poll command

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

[Xen-devel] [PATCH v6 05/18] xen/pvcalls: connect to a frontend

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

[Xen-devel] [PATCH v6 01/18] xen: introduce the pvcalls interface header

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:

[Xen-devel] [PATCH v6 03/18] xen/pvcalls: initialize the module and register the xenbus backend

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

[Xen-devel] [PATCH v6 13/18] xen/pvcalls: implement release command

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

[Xen-devel] [PATCH v6 11/18] xen/pvcalls: implement accept command

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

[Xen-devel] [PATCH v6 15/18] xen/pvcalls: implement the ioworker functions

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

[Xen-devel] [PATCH v6 18/18] xen: introduce a Kconfig option to enable the pvcalls backend

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

[Xen-devel] [PATCH v6 10/18] xen/pvcalls: implement listen command

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

[Xen-devel] [PATCH v6 17/18] xen/pvcalls: implement write

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

[Xen-devel] [PATCH v6 07/18] xen/pvcalls: implement socket command

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 ---

[Xen-devel] [PATCH v6 00/18] introduce the Xen PV Calls backend

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

Re: [Xen-devel] [PATCH v5 06/18] xen/pvcalls: handle commands from the frontend

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

Re: [Xen-devel] [PATCH 3/4] xen/mapcache: introduce xen_remap_cache_entry()

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

Re: [Xen-devel] [PATCH 2/4] xen/mapcache: add an ability to create dummy mappings

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

[Xen-devel] [PATCH v4 13/17] rbtree: add __rb_change_child() helper function

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

[Xen-devel] [PATCH v4 14/17] rbtree: place easiest case first in rb_erase()

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

[Xen-devel] [PATCH v4 15/17] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

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

[Xen-devel] [PATCH v4 17/17] rbtree: fix typo in comment of rb_insert_color

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

[Xen-devel] [PATCH v4 16/17] rbtree: low level optimizations in rb_erase()

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

[Xen-devel] [PATCH v4 11/17] rbtree: coding style adjustments

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

[Xen-devel] [PATCH v4 12/17] rbtree: optimize fetching of sibling node

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

[Xen-devel] [PATCH v4 09/17] rbtree: optimize case selection logic in __rb_erase_color()

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

[Xen-devel] [PATCH v4 10/17] rbtree: low level optimizations in __rb_erase_color()

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

[Xen-devel] [PATCH v4 08/17] rbtree: adjust node color in __rb_erase_color() only when necessary

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

[Xen-devel] [PATCH v4 07/17] rbtree: low level optimizations in rb_insert_color()

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

[Xen-devel] [PATCH v4 05/17] rbtree: break out of rb_insert_color loop after tree rotation

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

[Xen-devel] [PATCH v4 06/17] rbtree: adjust root color in rb_insert_color() only when necessary

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

[Xen-devel] [PATCH v4 04/17] rbtree: move some implementation details from rbtree.h to rbtree.c

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:

[Xen-devel] [PATCH v4 02/17] rbtree: remove redundant if()-condition in rb_erase()

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 { ...

[Xen-devel] [PATCH v4 01/17] rbtree: changes to inline coding conventions with Linux tree

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-devel] [PATCH v4 03/17] rbtree: empty nodes have no color

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

[Xen-devel] [PATCH v4 00/17] xen: common: rbtree: ported updates from Linux tree

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

[Xen-devel] [ovmf test] 111361: all pass - PUSHED

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

[Xen-devel] 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 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

[Xen-devel] What is provided with the Xen Tools and why do I need them?

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

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

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

Re: [Xen-devel] RT-Xen on ARM

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

Re: [Xen-devel] [RTDS Patch v3 for Xen4.8]

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

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

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

[Xen-devel] [xen-unstable-smoke test] 111364: tolerable trouble: broken/pass - PUSHED

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

[Xen-devel] [ovmf baseline-only test] 71627: tolerable FAIL

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-build

[Xen-devel] [linux-3.18 test] 111344: regressions - FAIL

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

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

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

Re: [Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

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

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Implement hvmemul_write() using real mappings

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

Re: [Xen-devel] [RTDS Patch v3 for Xen4.8]

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,

[Xen-devel] [xen-unstable baseline-only test] 71626: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [OSSTEST PATCH 3/3] db schema: Make the testid column NOT NLLL

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

[Xen-devel] [OSSTEST PATCH 1/3] mg-schema-test-database: Apply updates, regardless of compatibility

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

[Xen-devel] [OSSTEST PATCH 2/3] mg-schema-test-database: New --max-flight option

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

[Xen-devel] [OSSTEST PATCH 0/3] Schema tidying following recent changes

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

[Xen-devel] [linux-4.9 test] 111336: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v2 1/2] tools/libxc: add interface for GNTTABOP_query_size

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

Re: [Xen-devel] [PATCH v2 2/2] tools: utility to dump guest grant table info

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

Re: [Xen-devel] [PATCH 1/2] hvmloader: dynamically determine scratch memory range for tests

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

[Xen-devel] [RTDS Patch v3 for Xen4.8]

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

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

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; >>

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

>>> 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; > +

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Implement hvmemul_write() using real mappings

>>> 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; >>> +

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

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. >> */ >> /*

Re: [Xen-devel] [PATCH v5 03/11] x86/mce: handle host LMCE

>>> 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

[Xen-devel] [PATCH] xen/balloon: don't online new memory initially

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. BIOS reserved pages. Onlining new memory

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

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 world. Maybe we >>> should just add

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Implement hvmemul_write() using real mappings

On 22/06/17 10:06, Jan Beulich wrote: > >> +/* >> + * mfn points to the next free slot. All used slots have a page >> reference >> + * held on them. >> + */ >> +mfn_t *mfn = _ctxt->mfn[0]; >> + >> +/* >> + * The caller has no legitimate reason for trying a zero-byte

Re: [Xen-devel] RT-Xen on ARM

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 from RTDS? Currently we have no defined target use-cases. That's why we are

  1   2   >