On 24.09.19 14:08, Jan Beulich wrote:
On 24.09.2019 13:41, Jürgen Groß wrote:
Regarding to rename "sd" to "sr": I agree this would be a sensible
change. OTOH I'd like to be consistent, so I'd like to defer that to
the planned scheduling cleanup series.
Seeing another introduction of "sd" in a
On 25.09.2019 06:29, Juergen Gross wrote:
> vcpu_runstate_get() should never return a state entry time with
> XEN_RUNSTATE_UPDATE set. To avoid this let update_runstate_area()
> operate on a local runstate copy.
>
> This problem was introduced with commit 2529c850ea48f036 ("add update
> indicator
On 24.09.2019 19:58, Andrew Cooper wrote:
> On 20/09/2019 14:54, Jan Beulich wrote:
>> @@ -395,11 +395,20 @@ static void amd_xc_cpuid_policy(const st
>>
>> case 0x8008:
>> /*
>> - * ECX[15:12] is ApicIdCoreSize: ECX[7:0] is NumberOfCores (minus
>> one).
>> -
vcpu_runstate_get() should never return a state entry time with
XEN_RUNSTATE_UPDATE set. To avoid this let update_runstate_area()
operate on a local runstate copy.
This problem was introduced with commit 2529c850ea48f036 ("add update
indicator to vcpu_runstate_info").
Reported-by: Andrew Cooper
'len' in of_dma_get_range() is used to check the 'dma-ranges' property
length. After the fact, some calculations are run on the variable to be
then left unused.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Devices not represented in DT, placed behind a bus that autodetects
them, pass of_dma_configure() their bus' DT node. This misses that bus'
'dma-ranges' property as the function's implementation expects the DT
node to be one of a device.
Create of_dma_configure_parent() which takes the given DT no
Some devices don't have their own OF node, and are stuck passing their
bus node. Adapt the function for this use case.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 33 +++--
drivers/of/device.c| 3 ++-
include/linux/of_address.h |
The bus behind the board's PCIe core has DMA addressing limitations. Add
an empty 'dma-ranges' property on all PCIe bus descriptions to inform
the OF core that a translation is due further down the line.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |
The widespread use case for of_dma_config() highlights a redundant
argument. Most callers provide both 'dev' and 'dev->of_node'. The rest
of users use it to copy some device's DMA configuration into a device
not represented in DT.
In order to simplify the common use case, and make code a little m
The function provides the cell sizes for a specific bus type. Instead of
passing it the device DT node sitting on top of that bus we directly
pass its parent which is the actual node the function will start looking
from.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 18 ++
It's not longer advised to use notifiers in order to setup custom DMA
ops.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/device.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 267b509df517..018c52688546 100644
--- a/drivers/of/devi
Some devices might not have a DT node of their own, but might still need
to translate DMA addresses based on their bus DT node.
Update of_translate_dma_address() to only depend on the parent DT node.
Rename it to of_translate_dma_address_parent(). The later will be still
available as a wrapper aro
qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
which acts a bus in this regard. So far it maked all devices as
dma-coherent but no dma-ranges recommendation is made.
The truth is that the underlying interconnect has DMA constraints, so
add an empty dma-ranges in qoriq-mc'
The function was only available locally to of/address.c, make it
available to the OF subsystem.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c| 18 --
drivers/of/base.c | 25 +
drivers/of/of_private.h | 2 ++
3 files changed, 27
Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.
This is due to the fact that of_dma_configure() ass
Master PCI devices might not appear in the device tree, yet they still
need to get the underlying cells properties in order to calculate the
bus DMA constraints. This conflicts with of_n_*_cells() as it's designed
under the assumption it'll receive a device OF node.
Create __of_n_*_cells_parent()
On Mon, Jan 21, 2019 at 2:05 AM Mike Rapoport wrote:
>
> Hi,
>
> Current memblock API is quite extensive and, which is more annoying,
> duplicated. Except the low-level functions that allow searching for a free
> memory region and marking it as reserved, memblock provides three (well,
> two and a
On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 3. What to do with huge auto-generated commit 07? Should I split it
>>> per-maintainer or per-subsystem, or leave it as-is?
>>
>> It's big. I'd split it into multiple patches (and reduce the cc - except
>> for the cover letter, the rest o
24.09.2019 18:49, Vladimir Sementsov-Ogievskiy wrote:
> 24.09.2019 18:46, Vladimir Sementsov-Ogievskiy wrote:
>> 24.09.2019 18:44, Vladimir Sementsov-Ogievskiy wrote:
>>> 24.09.2019 18:28, Eric Blake wrote:
On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 3. What to do with
24.09.2019 18:28, Eric Blake wrote:
> On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
>
3. What to do with huge auto-generated commit 07? Should I split it
per-maintainer or per-subsystem, or leave it as-is?
>>>
>>> It's big. I'd split it into multiple patches (and reduce the cc
24.09.2019 18:44, Vladimir Sementsov-Ogievskiy wrote:
> 24.09.2019 18:28, Eric Blake wrote:
>> On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
> 3. What to do with huge auto-generated commit 07? Should I split it
> per-maintainer or per-subsystem, or leave it as-is?
It'
24.09.2019 18:46, Vladimir Sementsov-Ogievskiy wrote:
> 24.09.2019 18:44, Vladimir Sementsov-Ogievskiy wrote:
>> 24.09.2019 18:28, Eric Blake wrote:
>>> On 9/24/19 9:12 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>
>> 3. What to do with huge auto-generated commit 07? Should I split it
>> per-
flight 141742 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141742/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 670c903a68f214463f12c0c9619c162a0f342518
baseline version:
ovmf fcdedafd97c8f18c33a63
Stubdomains need to be given sufficient privilege over the guest which it
provides emulation for in order for PCI passthrough to work correctly.
When a HVM domain try to enable MSI, QEMU in stubdomain calls
PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq as
part of xc_domain_u
HVM domains use IOMMU and device model assistance for communicating with
PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
But pciback serve also second function - it reset the device when it is
deassigned from the guest and for this reason pciback needs to be used
with HVM dom
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
- Fixed code style
In this version, I drop PHYSDEVOP_interrupt_control patch, since Jan prefer not
to mix pciif and hypercalls for serving device model. Enabling MSI by the
stubdomain remains unsolved here, but other patches are improvement anyway.
Changes in v2:
- new "xen/x86: Allow stubdom access to irq created
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
flight 141729 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141599 REGR.
vs. 139698
Tests which
flight 141720 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141720/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail in 141650 pass in 141720
test-amd64-amd64-xl-pvshim 16 guest
flight 141783 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141783/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Now that vcpu_migrate_start() and vcpu_migrate_finish() are used only
> to ensure a vcpu is running on a suitable processor
>
Is this sentence like this (I mean with that "Now" at the beginning)
because it was --in previous versions of the
On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
wrote:
>
> Hi All,
> this series tries to address one of the issues blocking us from
> upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
> devices not represented in DT which sit behind a PCI bus fail to get the
> bus' DMA a
On Wed, 11 Sep 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/21/19 4:53 AM, Stefano Stabellini wrote:
> > Read the dtb fragment corresponding to a passthrough device from memory
> > at the location referred to by the "multiboot,device-tree" compatible
> > node.
> >
> > Add a new field named dt
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> sched_move_irqs() should work on a sched_unit as that is the unit
> moved between cpus.
>
> Rename the current function to vcpu_move_irqs() as it is still needed
> in schedule().
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggi
flight 141714 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-amd64-xl-qemuu-dmrest
flight 141778 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141763
build-armhf
Hi!
I'm a bit at a loss of what's happening here, but it seems that
the latest Xen from master fails to boot on HP ProLiant DL20
GEN10 server (same Xen boots fine on every other piece of
hardware in my lab).
There are absolutely no signs of what's going wrong with it.
It just stops at
(XEN) HVM:
On Wed, 11 Sep 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/21/19 4:53 AM, Stefano Stabellini wrote:
> > Add info about the SPI used for the virtual pl011.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v4:
> > - fix spelling
> > - add "multiboot,module"
> > - improve
Hi all,
On 9/24/19 6:17 PM, Julien Grall wrote:
Commit f855dd9625 "sched: add minimalistic idle scheduler for free cpus"
introduce the use of ZERO_BLOCK_PTR in the scheduler code. However, the
define does not exist outside of xmalloc_tsf.c for non-x86 architecture.
This will result to a compila
On 20/09/2019 14:54, Jan Beulich wrote:
> @@ -395,11 +395,20 @@ static void amd_xc_cpuid_policy(const st
>
> case 0x8008:
> /*
> - * ECX[15:12] is ApicIdCoreSize: ECX[7:0] is NumberOfCores (minus
> one).
> - * Update to reflect vLAPIC_ID = vCPU_ID * 2.
> +
On Wed, 11 Sep 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 8/21/19 4:53 AM, Stefano Stabellini wrote:
> > We don't have a clear way to know how many virtual SPIs we need for the
> > dom0-less domains. Introduce a new option under xen,domain to specify
> > the number of SPIs to allocate for a do
On Tue, 24 Sep 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 9/24/19 5:52 PM, Stefano Stabellini wrote:
> > On Wed, 11 Sep 2019, Julien Grall wrote:
> > > It also raises the question what should we do if the size passed in not
> > > page-aligned? Shall we just blindly round up/down? Should we war
On 24/09/2019 18:29, Dario Faggioli wrote:
> On Tue, 2019-09-24 at 12:15 +0100, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> After an extensive testing of your jgross1/sched-v3 branch in XenRT,
>> I'm happy to say that we've found no functional regressions so far
>> when running in the default (thread
On 24.09.19 20:21, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
[...]
int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
{
@@ -177,6 +241,13 @@ int iommu_do_dt_domctl(struct xen_domctl
*domctl, struct domain *d,
On Tue, 2019-09-24 at 12:15 +0100, Sergey Dyasli wrote:
> Hi Juergen,
>
> After an extensive testing of your jgross1/sched-v3 branch in XenRT,
> I'm happy to say that we've found no functional regressions so far
> when running in the default (thread/cpu) mode.
>
> Hopefully this gives some level
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Rename the scheduler related perf counters from vcpu* to unit* where
> appropriate.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software En
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Affinities are scheduler specific attributes, they should be per
> scheduling unit. So move all affinity related fields in struct vcpu
> to struct sched_unit. While at it switch affinity related functions
> in
> sched-if.h to use a pointer t
Hi Oleksandr,
On 9/24/19 5:22 PM, Oleksandr wrote:
On 24.09.19 18:57, Julien Grall wrote:
Hi,
Hi Julien
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
@@ -1263,15 +1264,22 @@ static int __init handle_device(struct domain
*d, struct dt_device_node *dev,
dt_dprintk("%s passthrough
On Sat, 2019-09-14 at 10:52 +0200, Juergen Gross wrote:
> Rename vcpu_schedule_[un]lock[_irq]() to
> unit_schedule_[un]lock[_irq]()
> and let it take a sched_unit pointer instead of a vcpu pointer as
> parameter.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
I guess 'No functio
Hi,
I forgot to CC the maintainers on it :/. Please ignore this e-mail.
Sorry for the noise.
Cheers,
On 9/24/19 6:17 PM, Julien Grall wrote:
Commit f855dd9625 "sched: add minimalistic idle scheduler for free cpus"
introduce the use of ZERO_BLOCK_PTR in the scheduler code. However, the
define
Commit f855dd9625 "sched: add minimalistic idle scheduler for free cpus"
introduce the use of ZERO_BLOCK_PTR in the scheduler code. However, the
define does not exist outside of xmalloc_tsf.c for non-x86 architecture.
This will result to a compilation error on Arm:
schedule.c: In function ‘sched_
Commit f855dd9625 "sched: add minimalistic idle scheduler for free cpus"
introduce the use of ZERO_BLOCK_PTR in the scheduler code. However, the
define does not exist outside of xmalloc_tsf.c for non-x86 architecture.
This will result to a compilation error on Arm:
schedule.c: In function ‘sched_
Hi Stefano,
On 9/24/19 5:52 PM, Stefano Stabellini wrote:
On Wed, 11 Sep 2019, Julien Grall wrote:
It also raises the question what should we do if the size passed in not
page-aligned? Shall we just blindly round up/down? Should we warn?
This was not important for dom0, but is potentially crit
On 24.09.19 18:51, Jan Beulich wrote:
Hi, Jan
On 24.09.2019 17:30, Oleksandr Tyshchenko wrote:
Changes V4 -> V5:
- avoid possible truncation with allocations of 4GiB or above
- introduce helper functions add(strip)_padding to avoid
duplicating the code
- omit the unneces
On Tue, 2019-09-24 at 17:10 +0200, Jürgen Groß wrote:
> On 24.09.19 14:08, Jan Beulich wrote:
> > On 24.09.2019 13:41, Jürgen Groß wrote:
> > > Regarding to rename "sd" to "sr": I agree this would be a
> > > sensible
> > > change. OTOH I'd like to be consistent, so I'd like to defer that
> > > to
On Tue, 2019-09-24 at 13:41 +0200, Jürgen Groß wrote:
> On 19.09.19 17:27, Jan Beulich wrote:
> > On 14.09.2019 10:52, Juergen Gross wrote:
> > >
> > > -DECLARE_PER_CPU(struct schedule_data, schedule_data);
> > > +#define curr_on_cpu(c)(get_sched_res(c)->curr)
> >
> > By moving this a few li
On 23.09.2019 10:17, Jan Beulich wrote:
Does booting with a single vCPU work?
Number of vCPUs make no difference
Well, according to Steven it does, with viridian=0. Could you
re-check this?
I can confirm that viridian=0 AND vcpus=1 makes the system bootable
(with long delay though)
at lea
On Wed, 11 Sep 2019, Julien Grall wrote:
> Hi,
>
> On 8/21/19 4:53 AM, Stefano Stabellini wrote:
> > Scan the user provided dtb fragment at boot. For each device node, map
> > memory to guests, and route interrupts and setup the iommu.
> >
> > The memory region to remap is specified by the "xen,r
Ping?
Since I've got an Ack from Jan and Julien I think the missing Acks are
for the Intel stuff and x86 generic and AMD by Andrew, since Jan
explicitly expressed his Ack is only for pieces where he is the only
maintainer.
Thanks.
On Thu, Aug 22, 2019 at 08:51:32AM +0200, Roger Pau Monne wrote:
flight 141763 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141763/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, 10 Sep 2019, Julien Grall wrote:
> Hi,
>
> On 8/21/19 4:53 AM, Stefano Stabellini wrote:
> > They'll be used in later patches.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v4:
> > - new patch
> > ---
> > xen/arch/arm/bootfdt.c| 8
> > xen/incl
On 24.09.19 18:57, Julien Grall wrote:
Hi,
Hi Julien
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
@@ -1263,15 +1264,22 @@ static int __init handle_device(struct domain
*d, struct dt_device_node *dev,
dt_dprintk("%s passthrough = %d nirq = %d naddr = %u\n",
dt_no
flight 141710 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 139891
test-amd64-i38
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal
to the P2M IPA size. It is not a problem when the IOMMU can support
all values the CPU supports. In that case, the IOMMU driver woul
Hi,
On 9/24/19 4:46 PM, Volodymyr Babchuk wrote:
OP-TEE mediator now is "Tech Preview" state, and we want to update
it's description in Kconfig accordingly.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
Cheers,
---
Note to commiter: this patch depends on first 4 patches in th
Hi Volodymyr,
On 9/24/19 4:46 PM, Volodymyr Babchuk wrote:
There is a case possible, when OP-TEE asks guest to allocate shared
buffer, but Xen for some reason can't translate buffer's addresses. In
this situation we should do two things:
1. Tell guest to free allocated buffer, so there will be
Hi,
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
@@ -1263,15 +1264,22 @@ static int __init handle_device(struct domain *d,
struct dt_device_node *dev,
dt_dprintk("%s passthrough = %d nirq = %d naddr = %u\n",
dt_node_full_name(dev), need_mapping, nirq, naddr);
-i
On 24.09.2019 17:30, Oleksandr Tyshchenko wrote:
> Changes V4 -> V5:
> - avoid possible truncation with allocations of 4GiB or above
> - introduce helper functions add(strip)_padding to avoid
> duplicating the code
> - omit the unnecessary casts, change u32 to uint32_t
> whe
There is a case possible, when OP-TEE asks guest to allocate shared
buffer, but Xen for some reason can't translate buffer's addresses. In
this situation we should do two things:
1. Tell guest to free allocated buffer, so there will be no memory
leak for guest.
2. Tell OP-TEE that buffer allocati
With the latest patches to the mediator, it can be considered
as Technological Preview feature.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
---
Note for commiter:
Obviously this patch should be merged after all other patches in
this series.
Changes from v2:
- ARM->Arm
- Added a-
OP-TEE mediator now is "Tech Preview" state, and we want to update
it's description in Kconfig accordingly.
Signed-off-by: Volodymyr Babchuk
---
Note to commiter: this patch depends on first 4 patches in the series.
---
xen/arch/arm/tee/Kconfig | 9 +
1 file changed, 5 insertions(+), 4
This is the third version of maturing the OP-TEE mediator patches.
Changes also can be pulled from [3].
Changes from v2:
- The following 3 patches were commited:
xen/arm: optee: impose limit on shared buffer size
xen/arm: optee: check for preemption while freeing shared buffers
xen/arm: optee
Hi Oleksandr,
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT bindings [1] which can be used for
both DT (right now) and ACPI (in future).
For that reason we can borrow th
On Fri, Sep 13, 2019 at 09:50:34AM -0700, Joe Jin wrote:
> On 9/13/19 3:33 AM, Roger Pau Monné wrote:
> > On Thu, Sep 12, 2019 at 11:03:14AM -0700, Joe Jin wrote:
> >> With below testcase, guest kernel reported "No irq handler for vector":
> >> 1). Passthrough mlx ib VF to 2 pvhvm guests.
> >>
Hi,
On 9/24/19 4:30 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Clean up the code a bit by putting the headers in alphabetical order.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
Cheers,
---
xen/drivers/passthrough/device_tree.c | 6 +++---
1 file change
On 9/24/19 4:37 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi,
On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
The documentation is using a mix of ARM (old) and Arm (new). To stay
consistent, use only the new name.
Honestly, this rename confuses me. I think, th
Julien Grall writes:
> Hi,
>
> On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>> consistent, use only the new name.
>>>
>> Honestly, this rename confuses me. I think, this commit is the good
>> plac
From: Oleksandr Tyshchenko
The main puprose of this patch is to add a way to register DT device
(which is behind the IOMMU) using the generic IOMMU DT bindings [1]
before assigning that device to a domain.
So, this patch adds new "iommu_add_dt_device" API for adding DT device
to the IOMMU using
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
R-Car Gen3 SoCs
From: Oleksandr Tyshchenko
We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT bindings [1] which can be used for
both DT (right now) and ACPI (in future).
For that reason we can borrow the idea used in Linux these days
called "iommu_fwspec". Having thi
From: Oleksandr Tyshchenko
The purpose of this patch series is to add IPMMU-VMSA support to Xen on ARM.
Besides new IOMMU driver, this series contains "iommu_fwspec" support
and new API iommu_add_dt_device() for adding DT device to IOMMU and many other
things.
The IPMMU-VMSA is VMSA-compatible
From: Oleksandr Tyshchenko
This patch introduces type-safe helper macros to re-allocate space
for a structure with a flexible array of typed objects.
For example, if we need to re-size the "data" array:
struct arrlen
{
size_t len;
int data[];
};
We can use the proposed mac
From: Oleksandr Tyshchenko
Introduce a separate file to keep various helpers which could be used
by more than one IOMMU driver in order not to duplicate code.
The first candidates to be moved to the new file are SMMU driver's
"map_page/unmap_page" callbacks. These callbacks neither contain any
S
From: Oleksandr Tyshchenko
This patch introduces type-unsafe function which besides
re-allocation handles the following corner cases:
1. if requested size is zero, it will behave like xfree
2. if incoming pointer is not valid (NULL or ZERO_BLOCK_PTR),
it will behave like xmalloc
If both point
From: Oleksandr Tyshchenko
Clean up the code a bit by putting the headers in alphabetical order.
Signed-off-by: Oleksandr Tyshchenko
---
xen/drivers/passthrough/device_tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/device_tree.c
b/xen/
From: Oleksandr Tyshchenko
This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.
In order not to pull Linux's error code (-EPROBE_DEFER) to Xen
we have chosen -EAGAIN to be used for indicating t
On 24.09.2019 17:20, Jürgen Groß wrote:
> On 24.09.19 12:05, Jan Beulich wrote:
>> On 14.09.2019 10:52, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -71,6 +71,7 @@ static void poll_timer_fn(void *data);
>>> /* This is global for now so that private i
Hi,
On 9/24/19 3:56 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
The documentation is using a mix of ARM (old) and Arm (new). To stay
consistent, use only the new name.
Honestly, this rename confuses me. I think, this commit is the good
place to clarify a couple of questions.
It did c
On 24.09.19 17:16, Jan Beulich wrote:
On 24.09.2019 09:42, Juergen Gross wrote:
vcpu_runstate_get() should never return a state entry time with
XEN_RUNSTATE_UPDATE set. To avoid this let update_runstate_area()
operate on a local runstate copy.
This problem was introduced with commit 2529c850ea4
On 24.09.2019 17:09, Jürgen Groß wrote:
> On 24.09.19 17:00, Jan Beulich wrote:
>> On 24.09.2019 16:41, Jürgen Groß wrote:
>>> On 23.09.19 17:41, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -1851,7 +1852,7 @@ void sched_context_switched(struct vcpu *vprev,
> stru
On 24.09.19 12:05, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -71,6 +71,7 @@ static void poll_timer_fn(void *data);
/* This is global for now so that private implementations can reach it */
DEFINE_PER_CPU(struct sch
Am Tue, 24 Sep 2019 15:17:43 +0100
schrieb Ian Jackson :
> I think the ability of the admin to edit these scripts is important and I
> have used it myself in the past.
Since they are scripts, they can be edited in any location. To me it is not
clear what the case would be to diverge from the v
On 24.09.2019 09:42, Juergen Gross wrote:
> vcpu_runstate_get() should never return a state entry time with
> XEN_RUNSTATE_UPDATE set. To avoid this let update_runstate_area()
> operate on a local runstate copy.
>
> This problem was introduced with commit 2529c850ea48f036 ("add update
> indicator
On 24.09.19 12:13, Jan Beulich wrote:
On 24.09.2019 12:06, Jürgen Groß wrote:
On 24.09.19 11:46, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
@@ -366,18 +380,38 @@ static void sched_free_unit(struct sched_unit *unit)
xfree(unit);
}
+static void sched_unit_add_vcpu
On 24.09.19 14:08, Jan Beulich wrote:
On 24.09.2019 13:41, Jürgen Groß wrote:
Regarding to rename "sd" to "sr": I agree this would be a sensible
change. OTOH I'd like to be consistent, so I'd like to defer that to
the planned scheduling cleanup series.
Seeing another introduction of "sd" in a
On 24.09.19 17:00, Jan Beulich wrote:
On 24.09.2019 16:41, Jürgen Groß wrote:
On 23.09.19 17:41, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
@@ -1851,7 +1852,7 @@ void sched_context_switched(struct vcpu *vprev, struct
vcpu *vnext)
while ( atomic_read(&next->ren
On 24.09.2019 17:00, Jürgen Groß wrote:
> On 24.09.19 14:31, Jan Beulich wrote:
>> On 24.09.2019 14:13, Jürgen Groß wrote:
>>> On 20.09.19 17:05, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -896,18 +929,22 @@ void restore_vcpu_affinity(struct domain *d)
>
On 24.09.2019 16:41, Jürgen Groß wrote:
> On 23.09.19 17:41, Jan Beulich wrote:
>> On 14.09.2019 10:52, Juergen Gross wrote:
>>> @@ -1851,7 +1852,7 @@ void sched_context_switched(struct vcpu *vprev,
>>> struct vcpu *vnext)
>>> while ( atomic_read(&next->rendezvous_out_cnt) )
>>>
On 24.09.19 14:31, Jan Beulich wrote:
On 24.09.2019 14:13, Jürgen Groß wrote:
On 20.09.19 17:05, Jan Beulich wrote:
On 14.09.2019 10:52, Juergen Gross wrote:
@@ -896,18 +929,22 @@ void restore_vcpu_affinity(struct domain *d)
cpupool_domain_cpumask(d));
if ( c
1 - 100 of 199 matches
Mail list logo
