> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 27 January 2017 23:35
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano
> Stabellini ; Anthony Perard
> ; Michael S. Tsirkin ; Paolo
> Bonzini ; Richard Henderson ;
flight 104989 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104989/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104886
test-armhf-armhf-libvirt 13
flight 68499 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68499/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail blocked in
68422
test-armhf-arm
The fail3 error path skips the va_end() call, which typically leaks memory for
64bit x86 code.
Introduced by c/s 524a98c2ac5, spotted by Coverity.
Coverity-ID: 1399608
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_private.c | 5 -
1 file changed, 4 insert
register_one_rmrr() already frees its parameter if errors are encountered.
Introduced by c/s 431685e8de and spotted by Coverity.
Coverity-ID: 1399607
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/dmar.c | 4
1 file changed, 4 deletions(-)
diff --git a/x
>>> On 27.01.17 at 18:22, wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
>> >>> On 19.01.17 at 18:29, wrote:
>> > +if ( cmdline != NULL )
>> > +{
>> > +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
>> > + strlen
>>> On 27.01.17 at 18:28, wrote:
> On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
>> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
>> > >>> On 19.01.17 at 18:29, wrote:
>> > > +if ( cmdline != NULL )
>> > > +{
>> > > +rc = hvm_copy_to_guest_phys_vc
On Mon, Jan 30, 2017 at 10:10:09AM +, Andrew Cooper wrote:
> The fail3 error path skips the va_end() call, which typically leaks memory for
> 64bit x86 code.
>
> Introduced by c/s 524a98c2ac5, spotted by Coverity.
>
> Coverity-ID: 1399608
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
_
>>> On 30.01.17 at 11:10, wrote:
> register_one_rmrr() already frees its parameter if errors are encountered.
>
> Introduced by c/s 431685e8de and spotted by Coverity.
>
> Coverity-ID: 1399607
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
I notice, however, that register_one_rmrr()
>>> On 27.01.17 at 20:43, wrote:
>> Despite being owned by the guest, this TSS is actually managed by
> Xen.
>> It should be initialised to defaults each time Xen needs to use it
> on
>> behalf of the guest.
>
> At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote:
>> On 27/01/17 14:01, Ti
Stefano Stabellini writes ("Re: [xen-4.8-testing test] 104736: regressions -
FAIL"):
> On Fri, 27 Jan 2017, Jan Beulich wrote:
> > of course I can't tell how urgent this fix was, but considering that
> > 4.8 has done fine so far without, may I ask that backports in the
> > common case get applied
On 30/01/17 10:43, Jan Beulich wrote:
On 27.01.17 at 20:43, wrote:
>>> Despite being owned by the guest, this TSS is actually managed by
>> Xen.
>>> It should be initialised to defaults each time Xen needs to use it
>> on
>>> behalf of the guest.
>> At 14:35 + on 27 Jan (1485527708), Andr
Stefano,
does the below look like you expected?
All, any comments/objections?
Thank you,
Oleksandr
On 01/26/2017 09:46 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/kbdif.h | 210 +
On 27/01/17 17:10, Dmitry Torokhov wrote:
> On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
>> On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
>>> On 01/27/2017 10:14 AM, Juergen Gross wrote:
On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
> On 01/27/2017 09:46 AM, Juergen G
On 01/30/2017 01:23 PM, Juergen Gross wrote:
On 27/01/17 17:10, Dmitry Torokhov wrote:
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
On 01/27/2017 10:14 AM, Juergen Gross wrote:
On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
O
On Fri, Jan 27, 2017 at 7:10 PM, Tamas K Lengyel
wrote:
> On Fri, Jan 27, 2017 at 11:30 AM, Andrew Cooper
> wrote:
>> On 27/01/17 18:22, Tamas K Lengyel wrote:
>>> On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote:
Hello,
In developing against the altp2m API, I've encountered so
Paul Durrant writes ("RE: [PATCH] xsm: Permit dom0 to use dmops"):
> I was unable to boot a guest under a flask enabled Xen without this patch,
> and able to boot after applying the patch so...
>
> Tested-by: Paul Durrant
In order to get staging un-broken I have pushed this now, even though
it'
On Thu, Jan 26, 2017 at 03:51:35AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44, wrote:
> > Some of them can be shared between hypervisor and userspace fuzzing /
> > test code. Instead of lifting the ones as we need, lift them all.
>
> While I appreciate the intention, I don't think we sh
On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >>> On 25.01.17 at 16:44, wrote:
> > ... so that they can be used by userspace x86 instruction emulator test
> > program and fuzzer as well.
>
> Ah, here we go. This should be patch 2 then imo.
>
> > --- /dev/null
> > +++ b/xen/inclu
On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> > >>> On 25.01.17 at 16:44, wrote:
> > > ... so that they can be used by userspace x86 instruction emulator test
> > > program and fuzzer as well.
> >
> > Ah, here we go. This
flight 104984 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254
test-amd64-i386-xl
flight 104981 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
104681
test-amd64-a
On Fri, Jan 27, 2017 at 12:13:58PM +0100, Juergen Gross wrote:
> On 24/01/17 17:42, Roger Pau Monné wrote:
> > Hello,
> >
> > The following commit:
> >
> > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > Author: Juergen Gross
> > Date: Tue Nov 22 07:10:58 2016 +0100
> >
> > xen: create qd
>>> On 30.01.17 at 13:46, wrote:
> On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> > >>> On 25.01.17 at 16:44, wrote:
>> > > ... so that they can be used by userspace x86 instruction emulator test
>> > > program and fuzze
flight 105009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105009/
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
On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 13:46, wrote:
> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >> > >>> On 25.01.17 at 16:44, wrote:
> >> > > ... so that they can be u
>>> On 30.01.17 at 15:17, wrote:
> On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
>> >>> On 30.01.17 at 13:46, wrote:
>> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> >> > >>> On 25.01.17 at 16:44, w
On Mon, Jan 30, 2017 at 07:24:57AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 15:17, wrote:
> > On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.17 at 13:46, wrote:
> >> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> >> On Thu, Jan 26, 2017 at 03
If we have no disk attached at startup, diskws is left unallocated
but `d_config.num_disks` may change if we attach a disk later.
When a domain is rebooted `evdisable_disk_ejects` is called
this will later result in a segfault if num_disks has changed.
Expand diskws when num_disks increases.
Sign
libxl_domain_build_info_dispose is not resetting the type field to
LIBXL_DOMAIN_TYPE_INVALID.
Instead, it is memseting the struct to 0 thus when
libxl_domain_build_info_init_type is called
after a dispose on the same struct, an assertion is triggered because type !=
LIBXL_DOMAIN_TYPE_INVALID.
Ca
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.
Signed-off-by: Juergen Gross
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2:
The error exits of xen_pv_find_xendev() free the new xen-device via
g_free() which is wrong.
As the xen-device has been initialized as qdev it must be removed
via qdev_unplug().
This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
("xen: create qdev for each backend device").
Report
Jan,
Sure. I will look in to it.
Venu
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 30, 2017 04:39 AM
> To: Andrew Cooper; Elena Ufimtseva; Venu Busireddy
> Cc: Xen-devel
> Subject: Re: [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_
Hi,
On 26/01/17 17:06, Wei Liu wrote:
On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote:
Hi,
On 09/12/2016 19:09, Andrew Cooper wrote:
On 09/12/16 19:01, Stefano Stabellini wrote:
On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
O
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed. Unfortunately
in the process, it added a filter to the generic p2m_flush_table()
function so that the p2m would only be flushed if it was being used as
a nested p2m. This meant
On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote:
[...]
> > > >
> > > > I think it would be good to main two lists. One of "the stuff people
> > > > are working on overall", and "the subset of it intended/expected for the
> > > > forthcoming release".
> > > >
> > > > Stuff will invar
On 30 January 2017 at 15:14, Juergen Gross wrote:
> The error exits of xen_pv_find_xendev() free the new xen-device via
> g_free() which is wrong.
>
> As the xen-device has been initialized as qdev it must be removed
> via qdev_unplug().
>
> This bug has been introduced with commit 3a6c9172ac5951e
On 30/01/17 16:46, Peter Maydell wrote:
> On 30 January 2017 at 15:14, Juergen Gross wrote:
>> The error exits of xen_pv_find_xendev() free the new xen-device via
>> g_free() which is wrong.
>>
>> As the xen-device has been initialized as qdev it must be removed
>> via qdev_unplug().
>>
>> This bu
Hi Stefano,
On 27/01/17 23:53, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Julien Grall wrote:
On 27/01/2017 20:41, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
For the second instance, we have no other choice.
Most alloc_heap_pages (alloc_xenheap_pages and alloc
On Mon, Jan 30, 2017 at 03:33:19PM +, Julien Grall wrote:
>
> == Testing ==
>
> * Continuous fuzzing of Xen code using Google oss-fuzz
> - Wei Liu
>
Stuck as we need someone to write the code to integrate things into
oss-fuzz.
Wei.
___
Xen-
flight 105021 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105021/
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
On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:
There are couple of problems with this patch.
1. The 'if' clause now evaluates to true on pretty much every call to
xennet_alloc_rx_buffers().
Thanks for catching this. In my testing I did not notice this - mostly
because of the nature of the wor
This results in rather more readable code. No functional change.
All fields currently specified are included, but commented out as no support
for their use is present.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmx.c| 41
The ept_get_*() helpers are not used consistently, and are more verbose than
the code they wrap. Drop the wrappers and use the internal union names
consistently.
While making these adjustments, drop the redundant ept_* prefix from mt, wl
and ad, and rename the asr field to mfn for consistency wit
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observ
Hi George,
yeap, this solves old mem_access settings being triggered when I
recreate altp2m views. Thanks!
On Mon, Jan 30, 2017 at 8:17 AM, George Dunlap wrote:
> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> nested p2m tables whenever the host p2m table changed. Unfortunat
On 01/30/2017 09:06 AM, Boris Ostrovsky wrote:
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
2. It tickles a latent bug during resume where the timer triggers
before we re-connect. The trouble is that we now try to dereference
queue->rx.sring which is NULL since we disconnect in
netfro
On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall wrote:
> Hi Stefano,
>
> On 27/01/17 23:53, Stefano Stabellini wrote:
>>
>> On Fri, 27 Jan 2017, Julien Grall wrote:
>>>
>>> On 27/01/2017 20:41, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
>>>
>>> For the second ins
From: "Edgar E. Iglesias"
The ZynqMP software stack has an extensive Firmware API.
Software at EL1 is increasingly dependant on this API. In fact,
a large set of use-cases for Linux already require access
to firmware. In a couple of months, we expect that most setups
will need it, so this is beco
From: "Edgar E. Iglesias"
Introduce platform_hvc as a way to handle hypercalls that
Xen does not know about in a platform specific way. This
is particularly useful for implementing the SiP (SoC
implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platform.c
From: "Edgar E. Iglesias"
Introduce call_smcc64, a helper function to issue 64-bit SMC
calls that follow the SMC Calling Convention. This includes
returning up to 4 64-bit values.
Signed-off-by: Edgar E. Iglesias
---
xen/include/asm-arm/processor.h | 40
From: "Edgar E. Iglesias"
Forward platform specific firmware calls from the hardware
domain to firmware.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/xen/arch/arm/platforms/xi
From: "Edgar E. Iglesias"
Stop blacklisting ZynqMP's power management node.
This is now possible since we allow the hardware domain to
issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 8
1 file changed, 8 deletions(-)
diff
From: "Edgar E. Iglesias"
Allow platform_hvc to handle guest SMC calls (as well as
HVC calls) in a platform specific way.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e8cd111..
From: "Edgar E. Iglesias"
Move the early setting of PSCI_RESULT_REG to a later stage
avoiding the early override of the FID that's stored in
the same register.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/traps.c | 7 +--
1 file changed, 5 insertions(+), 2 delet
The vTLB and last_write* booleans are used exclusively by the shadow pagetable
code. Move them from paging_vcpu to shadow_vcpu, which causes them to be
entirely omitted on a build without shadow paging support.
While changing the qualified names of these variables, drop an unnessary NULL
check be
No functional change yet, but required for subsequent changes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/arch/x86/domain.c | 3 ++-
xen/arch/x86/mm/hap/hap.c | 3 ++-
xen/arch/x86/mm/paging.c| 6 +++---
xen/arch/x86/mm/sh
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().
Signed-off-by: Boris
On 30/01/17 17:26, Andrew Cooper wrote:
> No functional change yet, but required for subsequent changes.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunlap
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> ---
> xen/arch/x86/domain.c | 3 ++-
> xen/arch/x86/mm/
On 30/01/17 16:54, Andrew Cooper wrote:
> The ept_get_*() helpers are not used consistently, and are more verbose than
> the code they wrap. Drop the wrappers and use the internal union names
> consistently.
>
> While making these adjustments, drop the redundant ept_* prefix from mt, wl
> and ad,
On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
> rx_refill_timer should be deleted as soon as we disconnect from the
> backend since otherwise it is possible for the timer to go off before
> we get to xennet_destroy_queues(). If this happens we may dereference
> queue->rx.sring which is
On Thu, Jan 19, 2017 at 02:01:03PM +0800, Yi Sun wrote:
> This patch creates L2 CAT feature document in doc/features/.
> It describes details of L2 CAT.
Perhaps also mention what is the title in the Intel SDM
to look into as well?
Perhaps:
"See Intel Resource Director Technology Monitoring Featur
On 01/30/2017 01:07 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
>> rx_refill_timer should be deleted as soon as we disconnect from the
>> backend since otherwise it is possible for the timer to go off before
>> we get to xennet_destroy_queues(). If this happe
We can switch ACPI from using fixmap to dynamic mapping as soon as
the system enters SYS_STATE_boot. This will allow us, for example,
to map MADT on systems with large number of processors where the
table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4).
Signed-off-by: Boris Ostrovsky
Hi,
after the two RFC versions now the first "serious" attempt for emulating
an ARM GICv3 ITS interrupt controller, for Dom0 only at the moment.
The ITS is an interrupt controller widget providing a sophisticated way
of dealing with MSIs in a scalable manner.
For hardware which relies on the ITS t
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer to the ITS h/w to create or alter the
LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Kconf
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can
The ability to clean a cache line is not only useful for EFI, but will
be needed later for the ITS support.
Export the function to be usable from the whole Xen/ARM code.
Signed-off-by: Andre Przywara
---
xen/arch/arm/efi/efi-boot.h | 1 -
xen/include/asm-arm/cache.h | 4
2 files changed, 4
The ARM GICv3 provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
r
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respective memory and enter each device into an rbtree to
late
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands fo
Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide for the ITS to use
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
requirement is only 256 Bytes, thus making mapping of several
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.
Since the final interrupt translation tables can be smaller than a page,
we map them on demand (which is
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-v3-its.c | 30 ++
1 file changed, 30 insert
If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.
Signed-of
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c | 34 +++
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).
Signed-off-by: Andre Przywara
---
xen/arch/arm/Makefi
To get MSIs from devices forwarded to a CPU, we need to name the device
and its MSIs by mapping them to an ITS.
Since this involves queueing commands to the ITS command queue, we can't
really afford to do this during the guest's runtime, as this would open
up a denial-of-service attack vector.
So w
Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.
Signed-off-by: Andre Przywara
---
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to a guest.
Signed-off-by: Andre Przywara
---
xen/arc
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
---
xen/arch/arm/vgic-v3-its.c | 33
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 35 +--
1 file changed, 33
Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Signed-off-by:
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-v3-its.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/a
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c | 88
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.
Signed-off-by: An
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-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 28
xen/arch/arm/vgic-v3.c | 12
xen/in
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.
Signed-off-by: Andre Przywara
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 or push virtual LPIs
to their VCPUs, also check the
George / Tamas,
I'm away from my dev machine so I cannot test. Thank you both for
working so quickly to resolve this behavior!
Best regards,
--Matt
On 01/30/2017 11:07 AM, Tamas K Lengyel wrote:
> Hi George,
> yeap, this solves old mem_access settings being triggered when I
> recreate altp2m vie
On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
> which is guarded by netif_carrier_ok() check.
Oh well, testing netif_carrier_ok() in pac
On 01/30/2017 02:06 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>
>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
>> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
>> which is guarded by netif_carrier_ok()
flight 105019 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105019/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 013927f81afb08e06314b66c8c8cd8549d5711c1
baseline version:
xtf 7e1bc8009286dcf505a1be
> > +# Testing
> > +
> > +L2 CAT uses same xl interfaces as L3 CAT/CDP. So, we can execute these
> > +commands to verify L2 CAT and L3 CAT/CDP on different HWs support them.
> > +
> > +For example:
> > +root@:~$ xl psr-hwinfo --cat
> > +Cache Allocation Technology (CAT): L2
> > +Socket
Hi all,
a couple of weeks ago I sent a detailed email asking for feedback on a
problem with Linux on Xen on ACPI systems:
http://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2
In short, on BUS_NOTIFY_ADD_DEVICE events, Linux (as Dom0) requests
stage-2 MMIO regions mappings via hypercall to
1 - 100 of 119 matches
Mail list logo
