>>> On 07.11.16 at 18:01, wrote:
> On 11/07/2016 06:10 PM, Jan Beulich wrote:
> On 07.11.16 at 16:24, wrote:
>>> The one-shot vm_event does sound reasonable. I could set a flag
>>> per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vector, and
>>> fire a single event from hvm_inject_
On 11/08/2016 10:15 AM, Jan Beulich wrote:
On 07.11.16 at 18:01, wrote:
>> On 11/07/2016 06:10 PM, Jan Beulich wrote:
>> On 07.11.16 at 16:24, wrote:
The one-shot vm_event does sound reasonable. I could set a flag
per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vect
There is no reason for the install-stubdom target to depend on
install-tools. It is absolutely reasonable to install new stubdoms
only.
Signed-off-by: Juergen Gross
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a8e9523..084588e 100644
flight 102026 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102026/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 101948
test-armhf-armhf-libvirt-qcow2 1
When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
flags not suitable for all stubdom builds (e.g. "-m64" often to be
found in $RPM_OPT_FLAGS will break building 32 bit stubdoms).
Signed-off-by: Juergen Gross
---
stubdom/Makefi
On 11/08/2016 10:15 AM, Jan Beulich wrote:
On 07.11.16 at 18:01, wrote:
>> On 11/07/2016 06:10 PM, Jan Beulich wrote:
>> On 07.11.16 at 16:24, wrote:
The one-shot vm_event does sound reasonable. I could set a flag
per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vect
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 November 2016 07:46
> To: Paul Durrant ; Wei Liu
> Cc: xen-devel ; net...@vger.kernel.org
> Subject: [PATCH v3] xen-netback: prefer xenbus_scanf() over
> xenbus_gather()
>
> For single items being collected thi
On 11/08/2016 11:19 AM, Razvan Cojocaru wrote:
> On 11/08/2016 10:15 AM, Jan Beulich wrote:
> On 07.11.16 at 18:01, wrote:
>>> On 11/07/2016 06:10 PM, Jan Beulich wrote:
>>> On 07.11.16 at 16:24, wrote:
> The one-shot vm_event does sound reasonable. I could set a flag
> per-VCPU,
On 11/08/2016 11:39 AM, Razvan Cojocaru wrote:
> On 11/08/2016 11:19 AM, Razvan Cojocaru wrote:
>> On 11/08/2016 10:15 AM, Jan Beulich wrote:
>> On 07.11.16 at 18:01, wrote:
On 11/07/2016 06:10 PM, Jan Beulich wrote:
On 07.11.16 at 16:24, wrote:
>> The one-shot vm_event does
On Tue, Nov 08, 2016 at 07:29:01AM +0100, Juergen Gross wrote:
> The dependency for setting up the links for ioemu is wrong: it is
> depending on tools/qemu-xen-traditional-dir which is being modified by
> each "make tools" call. This leads to rebuilds of several stubdom
> libraries for each call o
On Tue, Nov 08, 2016 at 09:29:11AM +0100, Juergen Gross wrote:
> There is no reason for the install-stubdom target to depend on
> install-tools. It is absolutely reasonable to install new stubdoms
> only.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
> ---
> Makefile | 2 +-
> 1 file cha
On Tue, Nov 08, 2016 at 10:09:41AM +0100, Juergen Gross wrote:
> When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
> EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
> flags not suitable for all stubdom builds (e.g. "-m64" often to be
> found in $RPM_OPT_FLAGS will break buildi
On 08/11/16 11:41, Wei Liu wrote:
> On Tue, Nov 08, 2016 at 07:29:01AM +0100, Juergen Gross wrote:
>> The dependency for setting up the links for ioemu is wrong: it is
>> depending on tools/qemu-xen-traditional-dir which is being modified by
>> each "make tools" call. This leads to rebuilds of seve
On Mon, Nov 07, 2016 at 12:53:29PM -0800, Stefano Stabellini wrote:
> On Mon, 7 Nov 2016, Anthony PERARD wrote:
> > When using QEMU for Xen PV guest, QEMU abort with:
> > xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type
> > generic-pc-machine
> >
> > This is because the
Hi all,
On 07/09/2016 18:56, Stefano Stabellini wrote:
On Wed, 7 Sep 2016, Julien Grall wrote:
On 30/08/2016 19:28, Ian Jackson wrote:
Julien Grall writes ("Moving Xen Project ACPI tables to xenbits"):
Some ACPI tables (STAO, XENV) are currently maintained by the Xen
Project and referenced on
On 07/11/2016 16:39, George John wrote:
Hi,
Hello,
(XEN) Freed 276kB init memory.
(XEN) traps.c:2505:d0v0 HSR=0x93820007 pc=0xc001d084 gva=0xe7804060
gpa=0x00e6160060
Looking at the log, DOM0 is trying to access an region that is not
mapped (0x00e6160060).
When booting Xen is g
flight 102029 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102029/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d66f85cb5eed5c218d822204897a78bab53fc157
baseline version:
ovmf 2998af862469c6a05657e
xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
which is then checked in hvm_do_resume(), and if != -1, a trap
is injected, regardless of whether vmx_idtv_reinject() has written
VM_ENTRY_INTR_INFO directly. If that's the case, the toolstack
injected interrupt will overwrite the reinj
Hi all,
I would like to start organizing a recurring community call to discuss
and sync-up on upcoming features for Xen ARM.
Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough
I would suggest to start with a 1 hour meeting on t
This run is configured for baseline tests only.
flight 68012 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68012/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2998af862469c6a05657e169d7def6f55420caad
baseline v
Hello Julien,
We will be happy to work on this. We are in GMT+2 timezone (EET).
Adding Artem Mygaiev and Oleksandr Tyshchenko who work on co-processor
sharing with me in EPAM.
Sincerely,
Andrii Anisov.
On Tue, Nov 8, 2016 at 2:19 PM, Julien Grall wrote:
> Hi all,
>
> I would like to start orga
>>> On 08.11.16 at 13:16, wrote:
> xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
> which is then checked in hvm_do_resume(), and if != -1, a trap
> is injected, regardless of whether vmx_idtv_reinject() has written
> VM_ENTRY_INTR_INFO directly. If that's the case, the toolstack
>
Oleksandr,
you may want to update the CC list, as there have been changes to
maintainership. Remove Ian Campell and Keir Fraser, add Stefano Stabellini
and Julien Grall . Also, as this
is a change in the Hypervisor, you probably want to use xen-devel@ as the main
mailing list. embedded-pv-dev
On 11/08/2016 03:10 PM, Jan Beulich wrote:
On 08.11.16 at 13:16, wrote:
>> xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
>> which is then checked in hvm_do_resume(), and if != -1, a trap
>> is injected, regardless of whether vmx_idtv_reinject() has written
>> VM_ENTRY_INTR_IN
Hi, Lars!
Thank you for your inputs,
I've just added the persons you mentioned to the CC list and hope that
someone
will have time to review the protocol.
Thank you,
Oleksandr
On 11/08/2016 03:11 PM, Lars Kurth wrote:
Oleksandr,
you may want to update the CC list, as there have been chang
Hi Julien,
I'm interested in joining. I'm in Sweden GMT+1.
Thanks!
Edgar
On Tue, Nov 08, 2016 at 12:19:52PM +, Julien Grall wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features t
The connect function prints an unintialized error code after an
earlier initialization was removed:
drivers/net/xen-netback/xenbus.c: In function 'connect':
drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This prints i
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 November 2016 13:35
> To: David Vrabel
> Cc: Arnd Bergmann ; Wei Liu ; Paul
> Durrant ; David S. Miller
> ; Juergen Gross ; Filipe Manco
> ; xen-de...@lists.xenproject.org;
> net...@vger.kernel.org; linux-ker...@v
Hi Julien,
On Tue, Nov 8, 2016 at 7:19 AM, Julien Grall wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
>
> On 8 Nov 2016, at 13:27, Oleksandr Andrushchenko wrote:
>
> Hi, Lars!
>
> Thank you for your inputs,
>
> I've just added the persons you mentioned to the CC list and hope that someone
>
> will have time to review the protocol.
...
>
> Yes, PV audio ABI update is also from us. Oleksandr ju
When using QEMU for Xen PV guest, QEMU abort with:
xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type
generic-pc-machine
This is because the machine 'xenpv' also use accel=xen. Moving the code
to xen_hvm_init() fix the issue.
This fix 021746c131cdfeab9d82ff918795a9f18d20
From: Iurii Konovalenko
Add support for the "Salvator-X" development board based on R-Car H3 SoC
which has SCIF compatible UART.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
xen/arch/arm/Rules.mk | 1 +
xen/arch/arm/arm64/debug-scif.inc | 51 ++
Hello Iurii,
Dirk (in CC) sent a similar patch few months ago to add support for this
board (see [1]).
I didn't ack the patch back then because I wanted to see documentation
on the wiki to bring up Xen on this board (see [2] for the
requirements). I didn't see any follow-up since then for th
On Tue, Nov 08, 2016 at 02:07:22PM +, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type
> generic-pc-machine
>
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to
CC: Andrew Cooper
Signed-off-by: Ian Jackson
---
make-flight | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/make-flight b/make-flight
index 7bb536f..a374884 100755
--- a/make-flight
+++ b/make-flight
@@ -463,7 +463,7 @@ do_xtf_tests () {
job_create_test test-xtf-$xena
Signed-off-by: Ian Jackson
CC: Andrew Cooper
---
ts-xen-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build b/ts-xen-build
index 80f6492..7cdd365 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -109,6 +109,7 @@ END
if test -f xen/Kconfig; then
echo >>xe
This will make life more convenient in a moment.
Signed-off-by: Ian Jackson
---
Osstest/BuildSupport.pm | 4
1 file changed, 4 insertions(+)
diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 7e114cf..4c2b658 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport
This requires an environment variable set in the build environment,
too. (There is an argument amongst hypervisor maintainers about
whether this requirement in xen.git is a good idea; but, nevertheless,
it is currently there in several existing trees, so we need to set
it.)
Signed-off-by: Ian Jac
On 08/11/16 15:09, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> CC: Andrew Cooper
> ---
> ts-xen-build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index 80f6492..7cdd365 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -109,6 +109,7 @@ END
>
On 08.11.2016 15:30, Julien Grall wrote:
Hello Iurii,
Dirk (in CC) sent a similar patch few months ago to add support for
this board (see [1]).
I didn't ack the patch back then because I wanted to see documentation
on the wiki to bring up Xen on this board (see [2] for the
requirements). I didn
Hello.
Please find inline the design doc for further CPUID improvements, planned for
development during the 4.9 timeframe.
A PDF version can be obtained from:
http://xenbits.xen.org/people/andrewcoop/cpuid-improvements-phase-2-v1.pdf
Comments welcome.
~Andrew
---8<---
% CPUID improvements,
Hello Dirk,
I have made only single change - I recompile ATF to leave CPU in EL2 mode
and reflash it.
Looks like this way are the mostly "correct" approach for this board.
All changes are made in publicly available sources, based on official
Renesas H3 yocto layer - https://github.com/renesas-rca
Dirk,
IuriiK did great work at the beginning of the summer to bringup XEN on
Salvator-X in a short term.
Due to different reasons it was a bit hacky and was not exposed here,
but you can find the stuff here:
https://github.com/qbeeukraine/meta-platform-xen. I'm not really sure
if the final code wa
flight 102014 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-libv
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 171ea82..ced7c92 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1392,6 +1392,72 @@ void hvm_ioreq_init(struct domain *d)
static int acpi_ioaccess(
int dir, unsigned int port, unsigned int bytes,
Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and instead adding the page offset directly in the memcpy
>>> On 08.11.16 at 16:35, wrote:
> Please find inline the design doc for further CPUID improvements, planned for
> development during the 4.9 timeframe.
Looks good, just a couple of minor remarks.
> ## Changes in hypercall behaviour
>
> During domain construction, some pieces of information cri
Hello Julien,
Yes, myself and a couple of others from DornerWorks are interested in
attending. We are in EST (GMT-5).
Stewart Hildebrand
Embedded Software Engineer
DornerWorks, Ltd
stewart.hildebr...@dornerworks.com
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Hello Julien,
I and Iurii Konovalenko are interesting in attending. We are in GMT+2
timezone.
With the best regards,
Iurii Mykhalskyi
On Tue, Nov 8, 2016 at 6:17 PM, Stewart Hildebrand <
stewart.hildebr...@dornerworks.com> wrote:
> Hello Julien,
>
> Yes, myself and a couple of others from Dorn
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>
Sounds good! EST (GMT-5).
Cheers,
-Chris
___
Xen-
On Tue, Nov 8, 2016 at 4:19 AM, Julien Grall wrote:
> Hi all,
>
...
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
I can't make it that week, b
Please include me in the invite. Mountain time (GMT-6)
On 11/8/2016 9:56 AM, Chris Patterson wrote:
I would suggest to start with a 1 hour meeting on the Wednesday 23rd
November. I know that people are spread across different timezones, so I
would like to gather thought before choosing a time
On 11/08/2016 11:22 AM, Roger Pau Monne wrote:
Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and in
I am interested, UTC -6.
On 11/08/2016 06:19 AM, Julien Grall wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss
> and sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
>
flight 102027 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-
On Tue, 8 Nov 2016, Julien Grall wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
On 08/11/16 16:32, Jan Beulich wrote:
On 08.11.16 at 16:35, wrote:
>> Please find inline the design doc for further CPUID improvements, planned for
>> development during the 4.9 timeframe.
> Looks good, just a couple of minor remarks.
>
>> ## Changes in hypercall behaviour
>>
>> During domain
This run is configured for baseline tests only.
flight 68011 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 9 xen-boot/src_ho
On 11/06/2016 04:42 PM, Boris Ostrovsky wrote:
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be needed by
PVH guests we will call this domctl for all (x86) guests for consistency.
Signed-off-by: Boris Ostrovsky
Ac
On Tue, 8 Nov 2016, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type
> generic-pc-machine
>
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to xen_hvm_init() fix the
Wei Liu, on Tue 08 Nov 2016 10:47:18 +, wrote:
> On Tue, Nov 08, 2016 at 10:09:41AM +0100, Juergen Gross wrote:
> > When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
> > EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
> > flags not suitable for all stubdom builds (e.g. "-m
Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.
However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the
This reverts commit 14fa16961b03a23e9b883e5f0ed06b6837a489d8.
Do not reintroduce platform_dom0_evtchn_ppi.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Release-acked-by: Wei Liu
---
xen/arch/arm/platform.c| 10 ++
xen/include/asm-arm/platform.h | 7 +++
2 files
Hi all,
the following commit:
commit 21550029f709072aacf3b90edd574e7d3021b400
Author: Julien Grall
Date: Thu Oct 8 19:23:53 2015 +0100
xen/arm: gic-v2: Automatically detect aliased GIC400
removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to
check whether the two GICC pag
> entered forwarding state
> Nov 7 18:10:30 colob NetworkManager[907]: (vif2.0-emu): enslaved
> to br0
> Nov 7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: brctl addif
> br0 vif2.0-emu failed
How come this failed?
> Nov 7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: ip
t tags/xen-20161108-tag
for you to fetch changes up to 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5:
xen: Fix xenpv machine initialisation (2016-11-08 11:17:30 -0800)
Xen
From: Anthony PERARD
When using QEMU for Xen PV guest, QEMU abort with:
xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type
generic-pc-machine
This is because the machine 'xenpv' also use accel=xen. Moving the code
to xen_hvm_init() fix the issue.
This fix 021746c131cdf
flight 102031 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102031/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-i386-l
flight 68013 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68013/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 67973
test-amd64-am
flight 102036 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102036/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fef15ecd20dd8db5bf0c33b00908fc59491dba8a
baseline version:
ovmf d66f85cb5eed5c218d822
Hi,
Apparently vif2.0-emu was already binded with br0 when "brctl addif br0
vif2.0-emu" failed.
root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl addif br0 vif2.0-emu
device vif2.0-emu is already a member of a bridge; can't enslave it to
bridge br0.
root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl show
br
On Wed, 28 Sep 2016, Andre Przywara wrote:
> Create a new file to hold the emulation code for the ITS widget.
> For now we 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 run is configured for baseline tests only.
flight 68015 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68015/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d66f85cb5eed5c218d822204897a78bab53fc157
baseline v
On Mon, Oct 31, 2016 at 05:48:23PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of the reads from int to unsigned,
> but these cases have been wrong before: negative values are not allowed
> for the modified cas
On Wed, 28 Sep 2016, Andre Przywara wrote:
> This introduces the ITS command handler for the CLEAR command, which
> clears the pending state of an LPI.
> This removes a not-yet injected, but already queued IRQ from a VCPU.
>
> In addition this patch introduces the lookup function which translates
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INT command sets a given LPI identified by a DeviceID/EventID pair
> as pending and thus triggers it to be injected.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/vgic-its.c | 34 ++
> 1 file changed, 34 in
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPC command associates a given collection ID with a given
> redistributor, thus mapping collections to VCPUs.
> We just store the vcpu_id in the collection table for that.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/vgic-its.c | 30 +++
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPD command maps a device by associating a memory region for
> storing ITTEs with a certain device ID.
> We just store the given guest physical address in the device table.
> We don't map the device tables permanently, as their alignment
> requireme
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
> pair and actually instantiates LPI interrupts.
> We allocate a new host LPI and connect that one to this virtual LPI,
> so that any triggering IRQ on the host can be quickly forwarded
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MOVI command moves the interrupt affinity from one redistributor
> (read: VCPU) to another.
> For now migration of "live" LPIs is not yet implemented, but we store
> the changed affinity in the host LPI structure and in our virtual ITTE.
>
> Signed-
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The DISCARD command drops the connection between a DeviceID/EventID
> and an LPI/collection pair.
> We mark the respective structure entries as not allocated and make
> sure that any queued IRQs are removed.
>
> Signed-off-by: Andre Przywara
> ---
> x
Hi, all,
Any comment or suggestion to this patch set? That would be very appreciated.
Thank you!
BRs,
Sun Yi
On 16-10-25 11:40:48, Yi Sun wrote:
> Hi all,
>
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
>
> Beside
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INV command instructs the ITS to update the configuration data for
> a given LPI by re-reading its entry from the property table.
> We don't need to care so much about the priority value, but enabling
> or disabling an LPI has some effect: We remove
This run is configured for baseline tests only.
flight 68016 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68016/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fef15ecd20dd8db5bf0c33b00908fc59491dba8a
baseline v
Hi Iurii,
On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
Hello Dirk,
I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.
Yes, this is what I meant with 'modifying firmware' ;)
You are loading Xen with U-Boot running in EL2, then?
With this modification,
On 08.11.2016 13:19, Julien Grall wrote:
Hi all,
I would like to start organizing a recurring community call to discuss
and sync-up on upcoming features for Xen ARM.
Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough
Would it be an op
86 matches
Mail list logo
