flight 109627 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109627/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b78f30d81d7e536df37bafb48c4cb5b6d44edb8
baseline version:
ovmf da0df6ca8f8f118866e53
flight 109603 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109603/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109561
test-armhf-armhf-libvirt 13 saveresto
flight 109623 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109623/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 1dce35a6400914276c71ae5ee981f84719a45da5
baseline version:
xtf 1538388f283a3cba96c081
On Thu, 11 May 2017, Andre Przywara wrote:
> When LPIs get unmapped by a guest, they might still be in some LR of
> some VCPU. Nevertheless we remove the corresponding pending_irq
> (possibly freeing it), and detect this case (irq_to_pending() returns
> NULL) when the LR gets cleaned up later.
> Ho
On Thu, 11 May 2017, Andre Przywara wrote:
> For LPIs the struct pending_irq's are dynamically allocated and the
> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
> at any time, teach the VGIC how to deal with irq_to_pending() returning
> a NULL pointer.
> We just do nothing
On Thu, 11 May 2017, Andre Przywara wrote:
> So far irq_to_pending() is just a convenience function to lookup
> statically allocated arrays. This will change with LPIs, which are
> more dynamic.
> The proper answer to the issue of preventing stale pointers is
> ref-counting, which requires more rew
On Fri, May 19, 2017 at 07:49:06PM +0100, Andrew Cooper wrote:
> From: Borislav Petkov
>
> We use sync_core() in the alternatives code to stop speculative
> execution of prefetched instructions because we are potentially changing
> them and don't want to execute stale bytes.
>
> What it does on
flight 109598 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 7 xen-buildfail REGR. vs. 109572
test-amd64-amd64-xl
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
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
d
Call inet_listen to implement the listen command.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen
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
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 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
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
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
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
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
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
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/pvcalls.h | 120
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
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
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
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
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 29 -
1 file changed, 28 insertion
Introduce a per-frontend data structure named pvcalls_back_priv. 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 re
Keep a list of connected frontends. Use a semaphore to protect list
accesses.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/xen/pvcalls-back.c
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...@
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
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 Thu, 18 May 2017, Stefano Stabellini wrote:
> On Wed, 17 May 2017, Juergen Gross wrote:
> > On 16/05/17 21:58, Stefano Stabellini wrote:
> > > On Tue, 16 May 2017, Juergen Gross wrote:
> > >> On 15/05/17 22:35, Stefano Stabellini wrote:
> > >>> The pvcalls backend has one ioworker per cpu: the i
flight 109624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109624/
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 12 mig
This run is configured for baseline tests only.
flight 71372 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71372/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109593 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
On Fri, May 19, 2017 at 11:17:24AM +0200, Jiri Slaby wrote:
> On 05/17/2017, 03:23 PM, Jiri Slaby wrote:
> >> So the initial CFI state is different between the two types of
> >> "functions". And there are a lot of other differences. C-type
> >> functions have to follow frame pointer conventions,
Hi Stefano,
On 18 May 2017 at 22:00, Stefano Stabellini wrote:
> Description of the problem: need for a place to run emulators and
> mediators outside of Xen, with low latency.
>
> Explanation of what EL0 apps are. What should be their interface with
> Xen? Could the interface be the regular hyp
flight 109621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109621/
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 12 mig
This run is configured for baseline tests only.
flight 71354 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 wind
This run is configured for baseline tests only.
flight 71359 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71359/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Fri, 19 May 2017, Jarvis Roach wrote:
> > While waiting for Jarvis and Edgar to provide more befitting information,
> > I'll
> > try to fill in myself. There is a demand to run "bare-metal" applications on
> > embedded boards (such as the new Xilinx Zynq MPSoC board). People in
> > those commun
As identified in Linux c/s c198b121b1a1d "x86/asm: Rewrite sync_core() to use
IRET-to-self", sync_core() is only appropriate for two very specific usecases.
Xen doesn't have need of either of these usecases, so drop sync_core() to
avoid any misuse.
In the unlikely event that we do gain a legitima
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: Friday, May 19, 2017 1:47 PM
> To: Zhongze Liu
> Cc: Wei Liu ; Stefano Stabellini
> ; xen-de...@lists.xenproject.org; Julien Grall
> ; Ian Jackson ; Jarvis
> Roach ; edg...@xilinx.com
> Subject: Re: Pro
From: Borislav Petkov
We use sync_core() in the alternatives code to stop speculative
execution of prefetched instructions because we are potentially changing
them and don't want to execute stale bytes.
What it does on most machines is call CPUID which is a serializing
instruction. And that's ex
On Fri, 19 May 2017, Julien Grall wrote:
> The same set of functions is used to set as well as to clean P2M
> entries, except for clean operations (INVALID_MFN ~0UL) is passed as a
> parameter. Unfortunately, when calculating an appropriate target order
> for a particular mapping INVALID_MFN is tak
On Sat, 20 May 2017, Zhongze Liu wrote:
> Hi, Wei,
>
> 2017-05-19 17:33 GMT+08:00 Wei Liu :
> > On Thu, May 18, 2017 at 11:09:40AM -0700, Stefano Stabellini wrote:
> >> > >
> >> > > Yes, those attributes are necessary and should be explicitly specified
> >> > > in the
> >> > > config file. I'
Hi, Wei,
2017-05-19 17:33 GMT+08:00 Wei Liu :
> On Thu, May 18, 2017 at 11:09:40AM -0700, Stefano Stabellini wrote:
>> > >
>> > > Yes, those attributes are necessary and should be explicitly specified
>> > > in the
>> > > config file. I'll add them in the next version of this proposal. And
>
2017-05-17 2:16 GMT+08:00 Stefano Stabellini :
> On Tue, 16 May 2017, Jan Beulich wrote:
>> >>> On 15.05.17 at 19:40, wrote:
>> > On Mon, 15 May 2017, Jan Beulich wrote:
>> >> >>> On 15.05.17 at 12:21, wrote:
>> >> > On Zhongze proposal, the share page will be mapped at the a specific
>> >> > add
Hello Sameer,
On 19/05/17 07:38, Goel, Sameer wrote:
On 12/29/2016 7:04 AM, Julien Grall wrote:
### Finding the StreamID and DeviceID
The static table IORT (see [5]) will provide information that will help to
deduce the StreamID and DeviceID from a given RID.
IORT table will also need s
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.12b-rc2-tag
xen: fixes for 4.12 rc2
It contains some fixes for the new Xen 9pfs frontend and some minor cleanups.
Thanks.
Juergen
arch/x86/xen/enlighten_pv.c | 15 ++-
arch/x
flight 109586 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 3 host-install(3)broken REGR. vs. 109490
test-xtf-amd64-
The same set of functions is used to set as well as to clean P2M
entries, except for clean operations (INVALID_MFN ~0UL) is passed as a
parameter. Unfortunately, when calculating an appropriate target order
for a particular mapping INVALID_MFN is taken into account which leads
to 4K page target ord
flight 109619 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109619/
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 12 mig
flight 109608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109608/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da0df6ca8f8f118866e53c7fb770598c13a6
baseline version:
ovmf f78c8bf2c64f57d5148be
This will make code a bit more readable, especially with changes that
will be introduced in subsequent patches.
Signed-off-by: Boris Ostrovsky
---
Change in v4:
* New patch
xen/common/page_alloc.c | 132 +++-
1 file changed, 74 insertions(+), 58 delet
Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.
Signed-off-by: Boris Ostrovsky
---
Changes in v4:
* Don't (debug-)scrub (and don't check for poison) before bootscrub completes
* Adjust scrub pattern
xen/Kconfig.de
. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
We keep track of the first unscrubbed page in a page buddy using first_dirty
field. For now it can have two values, 0 (whole buddy needs scrubbing) or
INVALID_DIRTY_IDX (the buddy does
Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.
Signed-off-by: Boris Ostrovsky
---
Changes in v4:
* Be careful with tasklets in idle_loop()
* Use per-cpu mapcache override
* Update node_to_scrub() algorithm to select clos
Changes in V4:
* Keep track of dirty pages in a buddy with page_info.u.free.first_dirty.
* Drop patch 1 (factoring out merge_and_free_buddy()) since there is only
one caller now
* Drop patch patch 5 (from V3) since we are not breaking partially-scrubbed
buddy anymore
* Extract search loop in al
While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.
Specifically, this feature will be needed by scrubbing code where
the scrubber,
When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.
Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_page
Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's PAGE_SCRUB_ABORT bit. The scrubber checks
Signed-off-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
xen/common/page_alloc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b365305..e744d81 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2292,6 +2292,
Today paravirtualization is a all-or-nothing game: either a kernel is
compiled with no paravirtualization support at all, or it is supporting
paravirtualized environments like Xen pv-guests or lguest additionally
to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen
HVM-guests.
As support
There is no need to include pv-guest only object files in a kernel not
configured to support those. Move Xen's irq.o, xen-asm*.o and pv parts
of entry_*.o into CONFIG_XEN_PV sections.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_32.S | 4 +++-
arch/x86/entry/entry_64.S | 6 --
arch/
paravirt_alloc_pmd_clone() doesn't exist anywhere. Remove its
prototype.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/pgalloc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index b2d0cd8288aa..71de65bb1791 100644
--
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_cpu_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_64.S | 4 +-
arch/x86/include/asm/deb
As there are now only very few pvops functions left when
CONFIG_PARAVIRT_FULL isn't set, merge the related structures into
one named "pv_ops".
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 32
arch/x86/include/asm/paravirt_types.h | 27
Add a new config item PARAVIRT_FULL. It will be used to guard the
pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests
and lguest) only.
Kernels not meant to support those guest types will be able to use many
operations without paravirt abstraction while still supporting all the
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_irq_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h| 44 +++--
Move members needed for fully paravirtualized guests only into a new
structure pvfull_info in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
Signed-off-by: Juergen Gross
---
arch/x86/boot/compressed/misc.h | 1 +
arch/x86/include/asm/paravirt.
As arch/x86/xen/irq.c is used for pv-guests only, there is no need to
have a test targeting a HVM guest in it. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/xen/irq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 33e92
Move functions needed for fully paravirtualized guests only into a new
structure pvfull_mmu_ops in paravirt_types_full.h, paravirt_full.h and
the associated vector into paravirt_full.c.
.flush_tlb_others is left in pv_mmu_ops as hyperv support will use it
soon.
Signed-off-by: Juergen Gross
---
paravirt_disable_iospace() isn't used anywhere. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 2 --
arch/x86/kernel/paravirt.c| 19 ---
2 files changed, 21 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/
>>> On 27.04.17 at 16:35, wrote:
> +static int vpci_modify_bars(struct pci_dev *pdev, const bool map)
> +{
> +struct vpci_header *header = &pdev->vpci->header;
> +unsigned int i;
> +int rc = 0;
> +
> +for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
> +{
> +paddr_t gadd
Hi all,
Xen tree is going to branch at 4.9 RC6. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another announcement will be made
when the moratorium is lifted.
Cheers,
--
Julien Grall
___
Andrew Cooper writes ("Re: [Xen-devel] Livepatching and Xen Security"):
> livepatching doesn't use libelf.
>
> It is a new ELF parsing implementation.
I don't think we care very much about bugs in the livepatching elf
parser. The livepatches are all completely trusted in any case.
Furthermore,
Andrew Cooper writes ("Re: [Xen-devel] [xen-4.8-testing test] 109585:
regressions - FAIL"):
> These are not actual regressions.
>
> test-hvm64-lbr-tsx-vmentry is generic test which runs on all hardware,
> but it triggers a host-specific failure mode on Intel Haswell processors
> and later.
...
>
On 19/05/17 15:32, Wei Liu wrote:
> On Thu, May 18, 2017 at 08:07:00PM +0100, Andrew Cooper wrote:
>> I would ask however how confident we are that there are no ELF parsing
>> bugs in the code? I think it might be very prudent to try and build a
>> userspace harness for it and let ALF have a go.
>
On Thu, May 18, 2017 at 08:07:00PM +0100, Andrew Cooper wrote:
> I would ask however how confident we are that there are no ELF parsing
> bugs in the code? I think it might be very prudent to try and build a
> userspace harness for it and let ALF have a go.
>
There is already a fuzzing harness i
On 19/05/17 14:20, osstest service owner wrote:
> flight 109585 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109585/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 45 xtf/tes
On 19/05/17 14:58, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
Regarding the branching, I was thinking to branch right after the next
RC. Any opinions on this?
That would be fine by me. We would want staging==master at the time
we branch, so we sh
Julien Grall writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> Regarding the branching, I was thinking to branch right after the next
> RC. Any opinions on this?
That would be fine by me. We would want staging==master at the time
we branch, so we should have a commit moratorium too.
Ian
>>> On 27.04.17 at 16:35, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -588,6 +588,51 @@ static void pci_enable_acs(struct pci_dev *pdev)
> pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
> }
>
> +int pci_size_bar(unsigned int seg
On 18/05/17 11:19, Andrew Cooper wrote:
On 16/05/17 11:16, Jan Beulich wrote:
First of all limit the memory range used for testing to 4Mb: There's no
point placing page tables right above 8Mb when they can equally well
live at the bottom of the chunk at 4Mb - rep_io_test() cares about the
5Mb.
Hi Andrew,
On 18/05/17 16:02, Andrew Cooper wrote:
On 18/05/17 15:31, Tim Deegan wrote:
Hi,
At 15:02 +0100 on 18 May (1495119734), Andrew Cooper wrote:
* When fabricating gl1e's from superpages, propagate the protection key as
well, so the protection key logic sees the real key as opposed
On Fri, May 19, 2017 at 02:23:42PM +0100, Julien Grall wrote:
> Hi,
>
> On 19/05/17 11:27, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
> > > On 18.05.17 at 17:38, wrote:
> > > > Modify Config.mk and Kconfig.debug to disable debug by default in
> > >
>>> On 27.04.17 at 16:35, wrote:
> And also allow it to do non-identity mappings by adding a new parameter. This
> function will be needed in other parts apart from PVH Dom0 build. While there
> fix the function to use gfn_t and mfn_t instead of unsigned long for memory
> addresses.
I'm afraid bo
Hi Ian,
On 18/05/17 19:11, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes"):
On 17/05/17 15:02, Julien Grall wrote:
For the last patch, at this stage of the release I would prefer to defer
it for Xen 4.10.
After reviewing these, I'd like to make a ca
>>> On 27.04.17 at 16:35, wrote:
> @@ -1048,6 +1050,24 @@ static int __init pvh_setup_acpi(struct domain *d,
> paddr_t start_info)
> return 0;
> }
>
> +int __init pvh_setup_ecam(struct domain *d)
While I won't object to the term ecam in title and description,
please use mmcfg uniformly i
Hi,
On 19/05/17 11:27, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] Use non-debug build for Xen 4.9"):
On 18.05.17 at 17:38, wrote:
Modify Config.mk and Kconfig.debug to disable debug by default in
preparation for late RCs and eventual release.
Signed-off-by: Julien Grall
To avoid
Hi,
On 19/05/17 13:09, Ian Jackson wrote:
Wei Liu writes ("[PATCH for-4.9] build: more adjustments to top-level Makefile
dependencies"):
In the original code, top-level dist target unconditionally invokes
dist target for tools/include, which is wrong when tools component is
not enabled.
Make
flight 109585 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 45 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 109515
test-xtf-amd64-
>>> On 19.05.17 at 11:52, wrote:
> I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
> yes I know - very old ;-), but the affected code hasn't much changed.
Well, at the very least I'd expect you to base your code on
4.4.4 plus the about 199 backports we've added there ove
Wei Liu writes ("[PATCH for-4.9] build: more adjustments to top-level Makefile
dependencies"):
> In the original code, top-level dist target unconditionally invokes
> dist target for tools/include, which is wrong when tools component is
> not enabled.
>
> Make dist-tools depend on dist-tools-publ
>>> On 19.05.17 at 13:16, wrote:
> On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
>> --- a/include/hw/i386/apic-msidef.h
>> +++ b/include/hw/i386/apic-msidef.h
>> @@ -26,6 +26,7 @@
>>
>> #define MSI_ADDR_DEST_ID_SHIFT 12
>> #define MSI_ADDR_DEST_IDX_SHIFT 4
>> -#d
On Thu, May 18, 2017 at 01:33:00AM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
> Interrupt Remapping -> Interrupt Request Formats On Intel 64
> Platforms, fields of MSI data register have changed. This patch
> avoids wrongly re
In the original code, top-level dist target unconditionally invokes
dist target for tools/include, which is wrong when tools component is
not enabled.
Make dist-tools depend on dist-tools-public-headers, which depends on
build-tools-public-headers.
Discovered by Travis-CI.
Signed-off-by: Wei Liu
>>> On 19.05.17 at 12:56, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [linux-linus test] 109469: regressions -
> FAIL"):
>> Therefore I'm afraid the only way we could obtain a more
>> complete picture would be if this re-occurred and if at that
>> time we'd have "async-show-all" in place on the
>>> On 27.04.17 at 16:35, wrote:
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -11,7 +11,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
> if (d_config->b_info.device_model_version !=
>
On Thu, May 18, 2017 at 01:32:59AM -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
> bind/unbind interfaces are added for this usage. This patch recogn
flight 109609 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109609/
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 12 mig
flight 109583 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 107636
test-amd64-i386-q
Jan Beulich writes ("Re: [Xen-devel] [linux-linus test] 109469: regressions -
FAIL"):
> Therefore I'm afraid the only way we could obtain a more
> complete picture would be if this re-occurred and if at that
> time we'd have "async-show-all" in place on the hypervisor
> command line.
Is that a th
1 - 100 of 115 matches
Mail list logo
