flight 113145 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm broken
build-armhf-xsm 5 host-build-
On Sat, Sep 09 2017 at 07:40:17 AM, Rajiv Ranganath
wrote:
[...]
>>
>> and do the same for the other components.
>
> Yes, we can do that, but I feel its a good idea. :-)
I meant to say _not_ a good idea! Sorry for the typo!
Best,
Rajiv
_
On Thu, Sep 07 2017 at 12:44:16 AM, Stefano Stabellini
wrote:
[...]
>> +[root@localhost ~]# ls /opt
>> +qemu-unstable stage1-xen xen-unstable xen-unstable-runit
>> +```
>> +
>> +This will extract all the build artifacts into `/opt` directory.
>
> Is there a reason to keep all the binaries u
On Thu, Sep 07 2017 at 12:29:54 AM, Stefano Stabellini
wrote:
[...]
>> +QEMU_BRANCH = 'master'
>
> I am not sure we want to checkout always the latest QEMU. It is a
> running target. It makes sense to use one of the latest releases
> instead, such as v2.10.0?
>
[...]
I feel once we have an u
On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini
wrote:
[...]
> The series is much better now thank you. One question: why did you write
> your own init scripts rather than reusing xencommons (with the caveat
> that you would have to add make sure to source_path.sh before running
> xenco
flight 113144 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113144/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 113128
build-arm64
This run is configured for baseline tests only.
flight 72078 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72078/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc
baseline v
On Fri, 11 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Implement the probe function for the pvcalls frontend. Read the
> > supported versions, max-page-order and function-calls nodes from
> > xenstore.
> >
> > Only one frontend<->backend connection is su
On Fri, 11 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Introduce a data structure named pvcalls_bedata. It contains pointers to
> > the command ring, the event channel, a list of active sockets and a list
> > of passive sockets. Lists accesses are protec
On Mon, 14 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Send data to an active socket by copying data to the "out" ring. Take
> > the active socket out_mutex so that only one function can access the
> > ring at any given time.
> >
> > If not enough room
On Sat, 12 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Send a PVCALLS_SOCKET command to the backend, use the masked
> > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
> > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the
On Mon, 14 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Implement recvmsg by copying data from the "in" ring. If not enough data
> > is available and the recvmsg call is blocking, then wait on the
> > inflight_conn_req waitqueue. Take the active socket in
On Tue, 15 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> > in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> > socket.
> >
> > For passive sockets, check whether we h
On Tue, 15 Aug 2017, Boris Ostrovsky wrote:
> > @@ -736,6 +755,104 @@ int pvcalls_front_accept(struct socket *sock, struct
> > socket *newsock, int flags)
> > return ret;
> > }
> >
> > +static unsigned int pvcalls_front_poll_passive(struct file *file,
> > +
On Mon, 14 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Introduce a waitqueue to allow only one outstanding accept command at
> > any given time and to implement polling on the passive socket. Introduce
> > a flags field to keep track of in-flight accept
On Mon, 14 Aug 2017, Boris Ostrovsky wrote:
> > > +
> > > +ret = bedata->rsp[req_id].ret;
> >
> > You can just return bedata->rsp[req_id].ret;
>
> Or maybe not. The slot may get reused by the time you get to the end.
Right!
> >
> > -boris
> >
> > > +/* read ret, then set this rsp slot
On Sat, 12 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Send PVCALLS_BIND to the backend. Introduce a new structure, part of
> > struct sock_mapping, to store information specific to passive sockets.
> >
> > Introduce a status field to keep track of the
flight 113139 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113139/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Sat, 12 Aug 2017, Boris Ostrovsky wrote:
> On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> > Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for
> > the active socket.
> >
> > Introduce fields in struct sock_mapping to keep track of active sockets.
> > Introduce a waitqu
flight 113149 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113149/
Perfect :-)
All tests in this flight passed as required
jobs:
build-amd64 pass
build-armhf pass
b
At 19:05 +0300 on 08 Sep (1504897532), Alexandru Isaila wrote:
> XSA-219 was discovered while trying to implement the bugfix in patch 4.
>
> Andrew Cooper (4):
> x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()
> [RFC] x86/hvm: Rename enum hvm_copy_result to hvm_translation_resul
On Fri, 8 Sep 2017, Roger Pau Monné wrote:
> On Thu, Sep 07, 2017 at 02:54:11PM -0700, Stefano Stabellini wrote:
> > On Thu, 31 Aug 2017, George Dunlap wrote:
> > > +### Direct-boot kernel image format
> > > +
> > > +Supported, x86: bzImage
> > > +Supported, ARM32: zImage
> > > +Support
Hi Bharat
On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil wrote:
> Hello Olensandr,
>
> I able to boot xen and trying to boot dom0 but there are no console log for
> dom0.
>
> following log for xen and it stuck booting dom0.
>
> (XEN) I/O virtualisation disabled
> (XEN) build-id: 7c2a3c70fb94754801d
On 09/08/2017 01:11 PM, Roger Pau Monné wrote:
> On Fri, Sep 08, 2017 at 10:56:33AM -0400, Boris Ostrovsky wrote:
>> I am slightly confused by the use of 'need_paging' variable in
>> dom0_compute_nr_pages().
>>
>> Because paging_mode_hap() and iommu_hap_pt_share are (almost?) always
>> true, we are
flight 113143 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113143/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc
baseline version:
ovmf c50596a701435b62dc7e9
flight 113141 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113141/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113032
test-armhf-armhf-libvirt 14 saveresto
On 08/09/17 18:33, Roger Pau Monné wrote:
> On Fri, Sep 08, 2017 at 10:00:41AM -0600, Jan Beulich wrote:
> On 08.09.17 at 16:30, wrote:
>>> On Fri, Sep 08, 2017 at 03:15:40PM +0100, Andrew Cooper wrote:
On 08/09/17 14:34, Roger Pau Monne wrote:
> While there fix the indentation.
>
On Fri, Sep 08, 2017 at 10:00:41AM -0600, Jan Beulich wrote:
> >>> On 08.09.17 at 16:30, wrote:
> > On Fri, Sep 08, 2017 at 03:15:40PM +0100, Andrew Cooper wrote:
> >> On 08/09/17 14:34, Roger Pau Monne wrote:
> >> > While there fix the indentation.
> >> >
> >> > Signed-off-by: Roger Pau Monné
>
On Fri, Sep 08, 2017 at 10:56:33AM -0400, Boris Ostrovsky wrote:
> I am slightly confused by the use of 'need_paging' variable in
> dom0_compute_nr_pages().
>
> Because paging_mode_hap() and iommu_hap_pt_share are (almost?) always
> true, we are not reducing available memory for PVH dom0 by page t
flight 113152 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113152/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/hvm/emulate.c| 40 ++--
xen/arch/x86/hvm/hvm.c| 56 +++
xen/arch/x86/hvm/intercept.c
From: Andrew Cooper
It will be reused by later changes.
Signed-off-by: Andrew Cooper
Signed-off-by: Alexandru Isaila
---
CC: Jan Beulich
Changes since V1:
- Changed param name
- Added ASSERT
---
xen/arch/x86/hvm/hvm.c| 144 +++---
From: Andrew Cooper
sh_emulate_map_dest() predates the introduction of the generic ERR_PTR()
infrastructure, but take the opportunity to avoid opencoding it.
The chosen error constants require need to be negative to work with IS_ERR(),
but no other changes.
Signed-off-by: Andrew Cooper
---
CC
XSA-219 was discovered while trying to implement the bugfix in patch 4.
Andrew Cooper (4):
x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()
[RFC] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result
x86/hvm: Break out __hvm_copy()'s translation logic
x86/hvm: Implemen
From: Andrew Cooper
An access which crosses a page boundary is performed atomically by x86
hardware, albeit with a severe performance penalty. An important corner case
is when a straddled access hits two pages which differ in whether a
translation exists, or in net access rights.
The use of hvm
flight 113137 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113137/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
As there is currently no user for sub-page grants or transient grants
remove that functionality. This at once makes it possible to switch
from grant v2 to grant v1 without restrictions, as there is no loss of
functionality other than the limited frame number width related to
the switch.
Signed-off
Based on the maximum page number of the host select either grant v1 or
grant v2.
For testing purposes add a way to specify the grant interface version
via a boot parameter.
Signed-off-by: Juergen Gross
---
drivers/xen/grant-table.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletio
Instead of having multiple variables with constants like
grant_table_version or grefs_per_grant_frame add those to struct
gnttab_ops and access them just via the gnttab_interface pointer.
Signed-off-by: Juergen Gross
---
drivers/xen/grant-table.c | 73
The grant v2 support was removed from the kernel with
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a ("xen/grant-table:
remove support for V2 tables") as the higher memory footprint of v2
grants resulted in less grants being possible for a kernel compared
to the v1 grant interface.
As machines wi
In order to support Linux to run as a pv guest on machines with huge
memory (>16TB) the kernel has to support grant table interface v2, as
v1 is limited to 32 bit frame numbers.
This series re-adds that support (it has been removed in 2015) and
restricts usage of v2 to the features of v1 in order
>>> On 08.09.17 at 16:30, wrote:
> On Fri, Sep 08, 2017 at 03:15:40PM +0100, Andrew Cooper wrote:
>> On 08/09/17 14:34, Roger Pau Monne wrote:
>> > While there fix the indentation.
>> >
>> > Signed-off-by: Roger Pau Monné
>> > ---
>> > Cc: Jan Beulich
>> > Cc: Andrew Cooper
>> > Cc: George Dunl
>>> On 08.09.17 at 16:41, wrote:
> On Mon, Sep 04, 2017 at 09:38:11AM -0600, Jan Beulich wrote:
>> >>> On 14.08.17 at 16:28, wrote:
>> > +/*
>> > + * At this point we have the following layout:
>> > + *
>> > + * Note that this refers to the position of the variables,
>> > + *
>>> On 08.09.17 at 08:56, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v)
> v->maptrack_tail = MAPTRACK_TAIL;
> }
>
> +int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
> +
On 08/09/17 16:49, Jan Beulich wrote:
On 08.09.17 at 08:56, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4631,40 +4631,19 @@ int xenmem_add_to_physmap_one(
>> {
>> struct page_info *page = NULL;
>> unsigned long gfn = 0; /* gcc ... */
>> -unsigned long pr
>>> On 08.09.17 at 08:56, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3824,8 +3824,15 @@ static int __init gnttab_usage_init(void)
> {
> BUILD_BUG_ON(DEFAULT_MAX_MAPTRACK_FRAMES < DEFAULT_MAX_NR_GRANT_FRAMES);
>
> +/*
> + * In case grant v2 is req
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
---
Cc: Andrew Cooper
Cc: Jan Beulich
---
xen/arch/x86/hvm/ioreq.c | 44 -
>>> On 08.09.17 at 08:56, wrote:
> @@ -1843,6 +1838,14 @@ gnttab_setup_table(
> gt = d->grant_table;
> grant_write_lock(gt);
>
> +if ( unlikely(op.nr_frames > gt->max_grant_frames) )
> +{
> +gdprintk(XENLOG_INFO, "Domain is limited to %d grant-table
> frames.\n",
> +
>>> On 08.09.17 at 08:56, wrote:
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Either do it from gnttab_setup_table() or just
> before the domain is started the first time.
The refer
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
On 08.09.2017 11:46, Samuel Thibault wrote:
Hello,
I'm all for it :)
Thanks!
I won't have time to spend for contributions, but I can probably answer
questions about the existing source code, challenges with stubdomains
etc.
Thanks for your offer. Stubdomains are definitely one of the use
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
This series introduces support for direct mapping of guest resources.
The resources are:
- Grant tables
- IOREQ server pages
NOTE: This series is based on a master re-base of Juergen Gross's patch "xen:
move
XENMAPSPACE_grant_table code into grant_table.c". For convenience the code is
also ava
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
This patch changes use of bool_t to bool in the ioreq server code. It also
fixes an incorrect indentation in a continuation line.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.
This patch adds a new memory op to allow such a resource
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
Since ioreq servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by
In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.
This patch removes a check which curr
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
>>> On 08.09.17 at 08:56, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -40,6 +40,44 @@
> #include
> #include
>
> +/* Per-domain grant information. */
> +struct grant_table {
> +/*
> + * Lock protecting updates to grant table state (version, active
> +
I am slightly confused by the use of 'need_paging' variable in
dom0_compute_nr_pages().
Because paging_mode_hap() and iommu_hap_pt_share are (almost?) always
true, we are not reducing available memory for PVH dom0 by page tables
size. But then in pvh_setup_p2m() we do use this memory by
paging_set
>>> On 08.09.17 at 08:56, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4631,40 +4631,19 @@ int xenmem_add_to_physmap_one(
> {
> struct page_info *page = NULL;
> unsigned long gfn = 0; /* gcc ... */
> -unsigned long prev_mfn, mfn = 0, old_gpfn;
> +unsigned lon
On Mon, Sep 04, 2017 at 09:38:11AM -0600, Jan Beulich wrote:
> >>> On 14.08.17 at 16:28, wrote:
> > +/*
> > + * At this point we have the following layout:
> > + *
> > + * Note that this refers to the position of the variables,
> > + * but the value has already changed from the
flight 113134 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113134/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Fri, Sep 08, 2017 at 03:15:40PM +0100, Andrew Cooper wrote:
> On 08/09/17 14:34, Roger Pau Monne wrote:
> > While there fix the indentation.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Konrad Rzes
On 09/08/2017 02:52 PM, Ian Jackson wrote:
> CC: George Dunlap
> Signed-off-by: Ian Jackson
This is a significant improvement, thanks:
Reviewed-by: George Dunlap
> ---
> README | 75
> --
> 1 file changed, 60 insertions(+), 1
On Fri, Sep 08, 2017 at 08:14:59AM -0600, Jan Beulich wrote:
> >>> On 08.09.17 at 15:44, wrote:
> > @@ -41,7 +41,7 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long
> > value, unsigned long old
> >value != old) &&
> > (!((value ^ old) & ad->monitor.write_ctrlreg_mas
On 08/09/17 14:34, Roger Pau Monne wrote:
> While there fix the indentation.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> ---
> xen
flight 113147 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113147/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 08.09.17 at 15:44, wrote:
> @@ -41,7 +41,7 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long
> value, unsigned long old
>value != old) &&
> (!((value ^ old) & ad->monitor.write_ctrlreg_mask[index])) )
> {
> -bool_t sync = !!(ad->monitor.write_ctr
flight 113129 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On 08.09.2017 16:44, Wei Liu wrote:
Signed-off-by: Wei Liu
---
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
---
xen/arch/arm/monitor.c| 4 ++--
xen/arch/x86/hvm/monitor.c| 10 +-
xen/common/monitor.c | 8
xen/include/asm-x86/hvm/monitor.h | 6 +
On 08/09/17 14:44, Wei Liu wrote:
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index a7ccfc4b42..b534dd3043 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -30,7 +30,7 @@
> #include
> #include
>
> -bool_t hvm_monitor_cr(unsigned in
On Fri, Sep 08, 2017 at 02:52:36PM +0100, Ian Jackson wrote:
> CC: George Dunlap
> Signed-off-by: Ian Jackson
Reviewed-by: Roger Pau Monné
Just one comment, which is probably pointless...
> ---
> README | 75
> --
> 1 file chan
CC: George Dunlap
Signed-off-by: Ian Jackson
---
README | 75 --
1 file changed, 60 insertions(+), 15 deletions(-)
diff --git a/README b/README
index ffe0018..93129e3 100644
--- a/README
+++ b/README
@@ -8,32 +8,55 @@ Terminology
flight 113132 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Fri, Sep 08, 2017 at 02:34:24PM +0100, Roger Pau Monne wrote:
> While there fix the indentation.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Signed-off-by: Wei Liu
---
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
---
xen/arch/arm/monitor.c| 4 ++--
xen/arch/x86/hvm/monitor.c| 10 +-
xen/common/monitor.c | 8
xen/include/asm-x86/hvm/monitor.h | 6 +++---
xen/include/xen/monitor.h
While there fix the indentation.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/passthrough/pci.c | 4 ++--
xen/include/xen/pci.h |
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2017 11:42
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH] x86/HVM: correct repeat count update in linear->phys
> translation
>
> For the insn emulator's fallback logic in REP
Hi Wei, Stefano,
Thank you so much for agreeing to be sponsors! I’ll update the document.
— Felipe
Dr. Felipe Huici
Chief Researcher, Networked Systems and Data
Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuer
This run is configured for baseline tests only.
flight 72074 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72074/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c50596a701435b62dc7e9c12b49201a17c38e17c
baseline v
>>> On 08.09.17 at 13:03, wrote:
> On 08/09/17 10:57, Jan Beulich wrote:
> On 07.09.17 at 18:50, wrote:
>>> map_domain_page_global() uses vmap under the hood, which works fine even
>>> during very early boot. Relax the local_irq_is_enabled() part of the
>>> assertion before Xen has finished
flight 72075 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72075/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64-pvops
On Wed, Sep 06, Andrew Cooper wrote:
> The stream has always been in-order for the first pass (even in the
> legacy days), and I don't forsee that changing. Reliance on the order
> was suggested by both myself and Jan during the early design.
A related question: is it save to increase MAX_BATCH_
On 08/09/17 10:57, Jan Beulich wrote:
On 07.09.17 at 18:50, wrote:
>> map_domain_page_global() uses vmap under the hood, which works fine even
>> during very early boot. Relax the local_irq_is_enabled() part of the
>> assertion before Xen has finished booting.
> vm_init() being called right
@Wei, @Stefano,
On 07/09/2017, 22:16, "Stefano Stabellini" wrote:
Hi all,
I would be glad to sponsor this proposal. I think it will be of great
benefit to the ecosystem. Let me know if I need to do anything specific.
Basically, all which is needed is an agreement. Which we
>>> On 07.09.17 at 18:50, wrote:
> map_domain_page_global() uses vmap under the hood, which works fine even
> during very early boot. Relax the local_irq_is_enabled() part of the
> assertion before Xen has finished booting.
vm_init() being called right after having reached SYS_STATE_boot
makes m
Hello,
I'm all for it :)
I won't have time to spend for contributions, but I can probably answer
questions about the existing source code, challenges with stubdomains
etc.
The only thing I'd worry about is to be clear on the scope of Unicore:
we don't want to just create another Linux kernel. Co
On Thu, Sep 07, 2017 at 02:54:11PM -0700, Stefano Stabellini wrote:
> On Thu, 31 Aug 2017, George Dunlap wrote:
> > +### Direct-boot kernel image format
> > +
> > +Supported, x86: bzImage
> > +Supported, ARM32: zImage
> > +Supported, ARM64: Image [XXX - Not sure if this is correct]
>
>
Hi Felipe
This is an awesome idea and I'm fully in support of this project. I'm
happy to be a project sponsor alongside Stefano.
Let me know if there is anything I need to do.
Wei.
On Thu, Sep 07, 2017 at 10:25:27AM +, Felipe Huici wrote:
> Dear all,
>
> Following up on discussions that Si
>>> On 07.09.17 at 19:36, wrote:
> On Wed, Aug 02, 2017 at 03:20:05AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 07/31/17 6:04 PM >>>
>> >On Mon, Jul 31, 2017 at 07:55:34AM -0600, Jan Beulich wrote:
>> >> >>> Konrad Rzeszutek Wilk 07/26/17 9:50 PM >>>
>> >> >--- a/docs/misc/livepatch
[Forgot two important details regarding Xenbus states]
On 09/07/2017 05:53 PM, Joao Martins wrote:
> Hey!
>
> We wanted to brought up this small proposal regarding the lack of
> parameterization on PV devices on Xen.
>
> Currently users don't have a way for enforce and control what
> features/qu
flight 113128 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113128/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 September 2017 15:23
> To: Paul Durrant
> Cc: Wei Liu ; xen-de...@lists.xenproject.org; Ian
> Jackson ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.o
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2017 16:17
> To: Roger Pau Monne ; Juergen Gross
>
> Cc: Paul Durrant ; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array
> of ioreq servers rather th
> -Original Message-
> From: Roger Pau Monne
> Sent: 07 September 2017 16:24
> To: Wei Liu
> Cc: Paul Durrant ; xen-de...@lists.xenproject.org;
> Stefano Stabellini ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v4 12/12] x86/hvm/ioreq: a
1 - 100 of 104 matches
Mail list logo
