This run is configured for baseline tests only.
flight 71332 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71332/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-build fa
flight 109490 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-
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 ioworkers are
>>> implemented as a cpu bound workqueue, and will deal with the actual
>>> socket and data ri
On 16/05/17 20:47, Wei Liu wrote:
> Wei Liu (2):
> tools/Rules.mk: honour CPPFLAGS in header check
> build: fix tools/include and stubdom build
>
> stubdom/Makefile | 13 +++--
> tools/Rules.mk | 2 +-
> tools/include/Makefile | 34 ++
>
flight 109489 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 45 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 109008
test-amd64-i386
flight 109475 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109475/
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
flight 109488 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
109085
test-amd6
(apologies re: the empty 'double tap' :-/ )
On 5/14/17 8:39 AM, Andrew Cooper wrote:
>> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
>
> What are you trying to achieve? It is still not clear despite all on
> this thread.
>
> The Linux HEPT error messages are non-ideal,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 109503 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109503/
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 71330 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71330/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-build
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> Xenconsole supports only PV console currently. This patch adds support
> for vuart console, which allows emulated pl011 UART to be accessed
> as a console.
>
> Signed-off-by: Bhupinder Thakur
> ---
>
> One review comment was to keep the vuart code u
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> Xenconsole supports only PV console currently. This patch adds support
> for supporting multiple consoles.
>
> This patch modifies different data structures and APIs used
> in xenconsole to support multiple consoles.
>
> Change summary:
>
> 1. Split
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> 1. Update documentation for a new vuart option added.
> 2. Update documentation about SPI irq reserved for vpl011.
>
> Signed-off-by: Bhupinder Thakur
> ---
>
> Changes since v2:
>
> - Incorporated the review comments on the documentation.
>
> do
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> The SBSA uart node format is as specified in
> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
>
> ARM SBSA defined generic UART
> --
> This UART uses a subset of the PL011 registers and conseque
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> Add a new console type VUART to connect to guest's emualated vuart
> console.
>
> Signed-off-by: Bhupinder Thakur
Reviewed-by: Stefano Stabellini
> ---
> tools/console/client/main.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> Allocate a new gfn to be used as a ring buffer between xenconsole
> and Xen for sending/receiving pl011 data.
>
> Signed-off-by: Bhupinder Thakur
Reviewed-by: Stefano Stabellini
> ---
>
> Changes since v2:
>
> - Removed the DOMCTL call to set t
flight 109478 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109478/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> An option is provided in libxl to enable/disable pl011 vuart while
> creating a guest domain.
>
> Libxl now suppots a generic vuart console and pl011 is a specific type.
> In future support can be added for multiple vuart of different types.
>
> User
flight 109469 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 109449
test-arm64-arm64-xl
On Wed, 10 May 2017, Bhupinder Thakur wrote:
> Add emulation code to emulate read/write access to pl011 registers
> and pl011 interrupts:
>
> - Emulate DR read/write by reading and writing from/to the IN
> and OUT ring buffers and raising an event to the backend when
> there is dat
flight 109477 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109477/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 7 host-ping-check-xen fail in 109446 pass in 109477
test-amd64-i386-xl-qemut-win7-amd
>>> + ret = xenbus_map_ring_valloc(dev, &req->u.connect.ref, 1, &page);
>>> + if (ret < 0) {
>>> + sock_release(map->sock);
>>> + kfree(map);
>>> + goto out;
>>> + }
>>> + map->ring = page;
>>> + map->ring_order = map->ring->ring_order;
>>> + /* first read
flight 109498 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 109495 REGR. vs.
109359
Tests whi
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:36 PM, Stefano Stabellini wrote:
> > 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 ind
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:35 PM, 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,
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
> > 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
On Tue, 16 May 2017, Stefano Stabellini wrote:
> > > diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> > > index 86eca19..876e577 100644
> > > --- a/drivers/xen/pvcalls-back.c
> > > +++ b/drivers/xen/pvcalls-back.c
> > > @@ -44,13 +44,100 @@ struct pvcalls_back_global {
> > >
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
> > 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 s
On Tue, 16 May 2017, Stefano Stabellini wrote:
> > And why are you using a rw semaphore --- I only noticed two instances of use
> > and both are writes.
>
> Yes, this is wrong, legacy from a previous version of the codebase. A
> simple spin_lock should suffice for this use-case.
I replied too qui
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
> > 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
On Mon, 15 May 2017, Boris Ostrovsky wrote:
> On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
> > The pvcalls backend has one ioworker per cpu: the ioworkers are
> > implemented as a cpu bound workqueue, and will deal with the actual
> > socket and data ring reads/writes.
> >
> > ioworkers are g
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 ioworkers are
> > implemented as a cpu bound workqueue, and will deal with the actual
> > socket and data ring reads/writes.
> >
> > ioworkers are global:
Use the common utility function, which contains checks on return values
and first calls F_GETFD as recommended by POSIX.1-2001, instead of
manually calling fcntl.
CID: 1374831
Signed-off-by: Stefano Stabellini
Reviewed-by: Eric Blake
Reviewed-by: Greg Kurz
CC: anthony.per...@citrix.com
CC: gr.
The Xen mapcache is able to create long term mappings, they are called
"locked" mappings. The third parameter of the xen_map_cache call
specifies if a mapping is a "locked" mapping.
>From the QEMU point of view there are two kinds of long term mappings:
[a] device memory mappings, such as option
From: Anthony PERARD
QEMU does not depends on libxencall, it was added because it was a
missing link dependency of libxendevicemodel, but now the later should
be built properly.
Signed-off-by: Anthony PERARD
Reviewed-by: Stefano Stabellini
---
configure | 2 +-
1 file changed, 1 insertion(+),
CID: 1374836
Signed-off-by: Stefano Stabellini
Reviewed-by: Eric Blake
Reviewed-by: Greg Kurz
CC: anthony.per...@citrix.com
CC: gr...@kaod.org
CC: aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/xen-9p-backend.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9p
The following changes since commit cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9:
block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170516-tag
for yo
On 05/16/2017 01:15 PM, Anoob Soman wrote:
> Hi,
>
> In our Xenserver testing, I have seen cases when we boot 50 windows
> VMs together, dom0 kernel softlocks up.
>
> The following is a brief description of the problem of what caused
> soflockup detection code to kick. A HVM domain boot generates a
On Thu, 11 May 2017, Paolo Bonzini wrote:
> On 09/05/2017 21:04, Stefano Stabellini wrote:
> > Assert that the return value is not an error. This issue was found by
> > Coverity.
> >
> > CID: 1374831
> >
> > Signed-off-by: Stefano Stabellini
> > CC: gr...@kaod.org
> > CC: pbonz...@redhat.com
> >
flight 109495 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 109359
Tests which
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
> >> > address in the guest memory. I agree this will require s
On Tue, 16 May 2017, Ian Jackson wrote:
> I think this discussion is rather too abstract. Can you give an
> example of a pair of apps that would usefully communicate using a
> shared memory page in this way ? Is one of these apps an unmodified
> bare metal app ?
That's a good idea. I CC'ed a cou
On Tue, May 16, 2017 at 03:54:37AM -0600, Jan Beulich wrote:
> >>> On 16.05.17 at 05:47, wrote:
> > I suspect the only paravirtualization needed is to
> > map the physical address of the soft|hard errors to which VM's memory
> > range was effected. What this effects is which VM should panic in c
flight 109466 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109466/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 5 xen-install fail REGR. vs. 109375
Tests which did not suc
On Tue, May 16, 2017 at 6:13 PM, Boris Ostrovsky
wrote:
> On 05/16/2017 11:52 AM, Gary R Hook wrote:
>> On 05/15/2017 09:54 PM, Boris Ostrovsky wrote:
>>>
>>
>> Possibly stupid question time...
>>
>>> On 05/15/2017 03:51 PM, Gary R Hook wrote:
>>>
2) Or, perhaps more importantly, what disti
Hi,
In our Xenserver testing, I have seen cases when we boot 50 windows VMs
together, dom0 kernel softlocks up.
The following is a brief description of the problem of what caused
soflockup detection code to kick. A HVM domain boot generates around
200K (evtchn:qemu-dm xen-dyn) interrupts, in
On 16/05/17 18:06, Tim Deegan wrote:
> At 17:51 +0100 on 16 May (1494957116), Andrew Cooper wrote:
>> c/s 4c5d78a10 was accidentally buggy when handling Protection Keys.
>> Protection keys applies to all user translations, not just accesses which
>> originate from user mode.
> Reviewed-by: Tim Deeg
On 05/16/2017 11:52 AM, Gary R Hook wrote:
> On 05/15/2017 09:54 PM, Boris Ostrovsky wrote:
>>
>
> Possibly stupid question time...
>
>> On 05/15/2017 03:51 PM, Gary R Hook wrote:
>>
>>> 2) Or, perhaps more importantly, what distinguishes said guest?
>>
>> Simplifying things a bit, it's an HVM gu
At 17:51 +0100 on 16 May (1494957116), Andrew Cooper wrote:
> c/s 4c5d78a10 was accidentally buggy when handling Protection Keys.
> Protection keys applies to all user translations, not just accesses which
> originate from user mode.
Reviewed-by: Tim Deegan
Does the test for write-protection jus
c/s 4c5d78a10 was accidentally buggy when handling Protection Keys.
Protection keys applies to all user translations, not just accesses which
originate from user mode.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Julien Grall
This regression was intro
On Fri, May 12, 2017 at 07:55:04AM -0600, Jan Beulich wrote:
> >>> On 19.04.17 at 17:11, wrote:
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -158,6 +158,62 @@ static int vioapic_read(
> > return X86EMUL_OKAY;
> > }
> >
> > +static int vioapic_dom0_map_gs
>>> On 16.05.17 at 17:55, wrote:
> On Fri, May 12, 2017 at 07:42:51AM -0600, Jan Beulich wrote:
>> >>> On 19.04.17 at 17:11, wrote:
>> > Note that currently there's no support for unbinding this interrupts.
>>
>> Do you plan to deal with that before this changes goes in? Aiui this
>> not working
On Fri, May 12, 2017 at 07:42:51AM -0600, Jan Beulich wrote:
> >>> On 19.04.17 at 17:11, wrote:
> > Note that currently there's no support for unbinding this interrupts.
>
> Do you plan to deal with that before this changes goes in? Aiui this
> not working means you can't pass through devices wit
Julien Grall writes ("Commit moratorium to staging"):
> It looks like osstest is a bit behind because of ARM64 boxes (they are
> fully loaded) and XP testing (they now have been removed see [1]).
>
> I'd like to cut the next rc when staging == master, so please stop
> committing today.
I force
On Tue, May 16, 2017 at 06:57:53PM +0300, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Initialise *size in default branch to prevent certain compilers (i.e.
> Linaro GCC 5.2-2015.11-2) from reporting "variable may be used uninitialized"
> errors in caller function.
>
> Signed-off-by: Julien Gr
From: Andrii Anisov
Initialise *size in default branch to prevent certain compilers (i.e.
Linaro GCC 5.2-2015.11-2) from reporting "variable may be used uninitialized"
errors in caller function.
Signed-off-by: Julien Grall
---
tools/libxl/libxl_arm_acpi.c | 1 +
1 file changed, 1 insertion(+)
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on a
On 05/16/2017 04:36 AM, Andrew Cooper wrote:
On 16/05/17 03:54, Boris Ostrovsky wrote:
2) Or, perhaps more importantly, what distinguishes said guest?
Simplifying things a bit, it's an HVM guest that doesn't have device
model (i.e. qemu) and which is booted directly (i.e. without hvmloader
On 05/15/2017 09:54 PM, Boris Ostrovsky wrote:
Possibly stupid question time...
On 05/15/2017 03:51 PM, Gary R Hook wrote:
2) Or, perhaps more importantly, what distinguishes said guest?
Simplifying things a bit, it's an HVM guest that doesn't have device
model (i.e. qemu) and which is
On Tue, May 16, 2017 at 06:14:43PM +0300, Andrii Anisov wrote:
> Dear Wei,
>
>
> On 16.05.17 14:03, Wei Liu wrote:
> > I'm confused by the commit message.
>
> My bad, I did not pay enough attention to write the message. Would following
> be better?
>
> Implicitly initialize a referenced oup
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusin
On Fri, May 12, 2017 at 03:02:29PM +0530, Bhupinder Thakur wrote:
[...]
> >> @@ -151,13 +154,19 @@ retry_transaction:
> >> if (rc) goto out;
> >>
> >> if (!libxl_only) {
> >> -rc = libxl__xs_write_checked(gc, t,
> >> GCSPRINTF("%s/frontend",libxl_path),
> >> -
Dear Wei,
On 16.05.17 14:03, Wei Liu wrote:
I'm confused by the commit message.
My bad, I did not pay enough attention to write the message. Would
following be better?
Implicitly initialize a referenced ouput parameter for all code
branches
in order to not face a "variable may be
On Wed, May 10, 2017 at 07:58:01PM +0530, Bhupinder Thakur wrote:
> index 2204425..f5dc62c 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -105,6 +105,7 @@ libxl_console_type = Enumeration("console_type", [
> (0, "UNKNOWN"),
> (1, "SERIAL"),
> (2,
osstest service owner writes ("[xen-unstable test] 109456: regressions - FAIL"):
> flight 109456 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109456/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> t
flight 109456 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR.
vs. 109136
Tests w
Andrew Cooper writes ("[PATCH for-4.9] tools/xenconsoled: Preserve errno while
rotating logfile handles"):
> The logic to optionally exit after a poll() error relies on errno, but
> handle_log_reload() does not preserve it.
>
> Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
This is an obv
The logic to optionally exit after a poll() error relies on errno, but
handle_log_reload() does not preserve it.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Julien Grall
For some reason which we haven't tracked down completely yet, an NTP time step
appears to reliably cau
George Dunlap writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL
support to VNC"):
> On 16/05/17 14:16, Ian Jackson wrote:
> > Simon: What is stopping you moving to a modern version of qemu ?
>
> I think from his previous query, it was the fact that there is no
> suitable stubdom for qemu
On 16/05/17 14:16, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL
> support to VNC"):
>> Hmm, I don't think this counts as "small patch with simple changes",
>> but I'll let Ian comment.
>
> I'm quite uneasy about this. It seems like the addition of
George Dunlap writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL
support to VNC"):
> Hmm, I don't think this counts as "small patch with simple changes",
> but I'll let Ian comment.
I'm quite uneasy about this. It seems like the addition of a lot of
code; effectively, a fork of the SASL
On Tue, May 16, 2017 at 12:03 AM, Simon Waterman
wrote:
> This patch series back-ports SASL authentication from
> upstream QEMU to the VNC server in qemu-xen-traditional.
> It enables authentication to the VNC console of a domain
> to be controlled using any SASL mechanism when using an
> IOEMU st
>>> On 16.05.17 at 14:48, wrote:
> On Mon, May 15, 2017 at 3:33 PM, Jan Beulich wrote:
> On 15.05.17 at 12:43, wrote:
>>> Indeed, there was some misunderstanding from my side on this.
>>> Let me elaborate a bit more on this:
>>> 1. Yes, this TODO shouldn't be just dropped, but needs to be
>>
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
This remove
Hi, Jan
On Mon, May 15, 2017 at 3:33 PM, Jan Beulich wrote:
On 15.05.17 at 12:43, wrote:
>> On Mon, May 15, 2017 at 10:22 AM, Jan Beulich wrote:
>> On 12.05.17 at 18:25, wrote:
On Fri, May 12, 2017 at 7:17 PM, Jan Beulich wrote:
On 12.05.17 at 17:50, wrote:
>> On F
On 05/16/2017 03:41 AM, Juergen Gross wrote:
> There are some leftovers testing for pvh guest mode in pv-only source
> files. Remove them.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.or
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to clean it up and re-initialize it later on.
Export vgic_init_pending_irq() and extend it to be reusable.
Si
>>> On 16.05.17 at 13:52, wrote:
> On Wed, Apr 19, 2017 at 04:11:26PM +0100, Roger Pau Monne wrote:
> [...]
>> +if ( *pirq_p < 0 )
>> +{
>> +if ( pirq )
>> +{
>> +dprintk(XENLOG_G_ERR, "dom%d: %d:%d already mapped to %d\n",
>> +d->domain_id,
>>> On 16.05.17 at 11:47, wrote:
> On Fri, May 12, 2017 at 06:56:01AM -0600, Jan Beulich wrote:
>> >>> On 19.04.17 at 17:11, wrote:
>> > +pcidevs_lock();
>> > +/* Verify or get pirq. */
>> > +spin_lock(&d->event_lock);
>> > +pirq = domain_irq_to_pirq(d, irq);
>> > +
>> > +if (
Wei Liu, on mar. 16 mai 2017 11:47:30 +0100, wrote:
> Build can fail if stubdom build is run before tools build because:
>
> 1. tools/include build uses relative path and depends on XEN_OS
> 2. stubdom needs tools/include to be built, at which time XEN_OS is
>mini-os and corresponding symlinks
On Mon, 2017-05-15 at 15:32 +0100, George Dunlap wrote:
> On Mon, May 15, 2017 at 2:35 PM, Andrew Cooper
> wrote:
> > On systems with this number of in-flight interrupts, trying to
> > track
> > "who got what interrupt" for priority
> > boosting purposes is a waste of
> > time, as we spend ages ta
On Wed, Apr 19, 2017 at 04:11:26PM +0100, Roger Pau Monne wrote:
[...]
> +if ( *pirq_p < 0 )
> +{
> +if ( pirq )
> +{
> +dprintk(XENLOG_G_ERR, "dom%d: %d:%d already mapped to %d\n",
> +d->domain_id, *index, *pirq_p, pirq);
> +if (
On Tue, May 16, 2017 at 08:59:25AM +0100, Roger Pau Monne wrote:
> Move the device addition/removal code to the {add/remove}_device functions.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
On Tue, May 16, 2017 at 12:03:49PM +0100, Wei Liu wrote:
> On Tue, May 16, 2017 at 01:59:40PM +0300, Andrii Anisov wrote:
> > CC Ian Jakson and Wei Liu as maintainers.
> >
> > Sincerely,
> > Andrii Anisov.
> >
> > 2017-05-16 13:23 GMT+03:00 Andrii Anisov :
> >
> > > From: Andrii Anisov
> > >
>
On Mon, May 15, 2017 at 07:09:54PM +, Bill Jacobs (billjac) wrote:
> > -Original Message-
> > From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
> > Sent: Monday, May 15, 2017 6:13 AM
> > To: Bill Jacobs (billjac) ; george.dun...@citrix.com
> > Cc: xen-devel@lists.xen.org; xen-us...@li
Stefano Stabellini writes ("Re: [Xen-devel] Proposal to allow setting up shared
memory areas between VMs from xl config file"):
> Bare-metal apps already have the concept of a shared page to communicate
> with hardware devices, co-processors and other hardware/firmare
> intercommunication framewor
On Tue, May 16, 2017 at 01:59:40PM +0300, Andrii Anisov wrote:
> CC Ian Jakson and Wei Liu as maintainers.
>
> Sincerely,
> Andrii Anisov.
>
> 2017-05-16 13:23 GMT+03:00 Andrii Anisov :
>
> > From: Andrii Anisov
> >
> > Some compilers do not (validly?) detect that size will always be
> > initia
CC Ian Jakson and Wei Liu as maintainers.
Sincerely,
Andrii Anisov.
2017-05-16 13:23 GMT+03:00 Andrii Anisov :
> From: Andrii Anisov
>
> Some compilers do not (validly?) detect that size will always be
> initialized when (rc > 0), so implicitly initialize it.
>
> Signed-off-by: Julien Grall
>
Build can fail if stubdom build is run before tools build because:
1. tools/include build uses relative path and depends on XEN_OS
2. stubdom needs tools/include to be built, at which time XEN_OS is
mini-os and corresponding symlinks are created
3. libraries inside tools needs tools/include to
It could contain vital information about header location in a
cross-build environment like stubdom.
Signed-off-by: Wei Liu
---
Cc: Steven Haigh
Cc: Ian Jackson
Cc: Julien Grall
---
tools/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.
Wei Liu (2):
tools/Rules.mk: honour CPPFLAGS in header check
build: fix tools/include and stubdom build
stubdom/Makefile | 13 +++--
tools/Rules.mk | 2 +-
tools/include/Makefile | 34 ++
3 files changed, 22 insertions(+), 27 deletions(-)
Hello All,
On 08.05.17 21:41, Julien Grall wrote:
Hi all,
Xen 4.9 rc4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.9.0-rc4
With the build fix patch [1] the RC is tested on M3ULCB (Renesas M3)
board [2].
System build done with Yocto.
Following is functi
Julien Grall writes ("Re: [PATCH v2 1/2] libxl/devd: fix a race with concurrent
device addition/removal"):
> Is this patch series targeting Xen 4.9?
IMO it should be. The changes are confined to the xl devd code, which
is currently broken. So the reward/risk ratio is good.
Ian.
__
Julien Grall writes ("Re: [PATCH for-4.9] ioemu-stubdom: don't link *-softmmu*
and *-linux-user*"):
> On 12/05/17 17:23, Wei Liu wrote:
> > On Fri, May 12, 2017 at 04:21:06PM +0100, Wei Liu wrote:
> >> They are generated by ./configure. Having them linked can cause race
> >> between tools build an
flight 71324 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71324/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start fail blocked in 71268
test-amd64-amd
From: Andrii Anisov
Some compilers do not (validly?) detect that size will always be
initialized when (rc > 0), so implicitly initialize it.
Signed-off-by: Julien Grall
---
tools/libxl/libxl_arm_acpi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/l
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...7Mb range only anyway. In a subsequent patch this will then also
allow simply loo
>>> 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
>> > address in the guest memory. I agree this will require some work in the
>> > toolstack, on the hypervisor
1 - 100 of 118 matches
Mail list logo
